Re: There appears to be a server...
On Fri, 21 Dec 2007 21:39:00 -0600, Ed Gould [EMAIL PROTECTED] wrote: There appears to be a sever sending messages twice to the IBM-MAIN server tonight. I have gotten back at least 10 rejected postings as duplicates. Is anyone else experiencing this? I'm not experiencing it, but I post via the web interface. If you examine the headers of the messages (the various Received: ... lines) you can tell which server is doing it. And you might contact the list administrator and ask him to set the users of that server to nomail until they get it fixed. -- Walt -- 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: FICON vs ESCON CTC's
On Fri, 21 Dec 2007 18:28:18 -0500, Dave Barry [EMAIL PROTECTED] wrote: Job A on system A issues static SQL query to DB2 on system B. Which is faster: 1) DDF call to DB2 on system B via APPC over FICON CTC or 2) Local call to DB2 member of datasharing group w/ FICON CF links? Considering the overhead of DRDA protocol and independent enclave creation/classification/scheduling, etc., I would guess option 2 is more efficient in terms of CPU and response time. I'm just not sure how to determine in theory to what degree. db #2 for sure. BTDTGTTS. That is the whole point of high speed data sharing (|| sysplex). 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: Problem fetching a program object (CSV031I)
Was this done for a reason, I presume you're asking why validation data is kept and validation is done? I don't really know the history behind this, but validation is rarely a bad thing, Besides, system services are provided to be used. It is perhaps related also to the fact that additional data needs to be managed for relocation purposes to accommodate relocation spanning a page boundary. Peter Relson z/OS Core Technology Design -- 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: Problem fetching a program object (CSV031I)
On Dec 22, 2007, at 12:10 PM, Peter Relson wrote: Was this done for a reason, I presume you're asking why validation data is kept and validation is done? I don't really know the history behind this, but validation is rarely a bad thing, Besides, system services are provided to be used. It is perhaps related also to the fact that additional data needs to be managed for relocation purposes to accommodate relocation spanning a page boundary. Peter: Thanks for the update. I m not agreeing or disagreeing on anything just noting that this *seems* to be a change behavior of a product. Was this flagged somewhere at IBM and customers notified of the change of behavior (in advance)? Ed -- 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
DSLIST DELETE VSAM Dialog
I have long been annoyed by the dialog that ISPF DSLIST presents me for each VSAM data set present when I delete a bunch of data sets. I have no idea what it wants to know; I just press ENTER each time and sooner or later it finishes deleting the data set and moves on to the next one. Today, I deleted a bunch of data sets that HSM had migrated. I noticed to my surprise and delight that it presented no dialog to confirm or alter the deletion. I will now HMIGRATE each VSAM data set before deleting a bunch. Silicon is cheaper than carbon. Yet, I wonder: if that dialog is essential, or even important, for deleting VSAM data sets, why is it not presented alike for migrated and resident VSAM data sets? I don't think I'll start a PMR on it; if IBM chose to fix it, I'd have shot myself in the foot. -- gil -- 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: DSLIST DELETE VSAM Dialog
Gil, Are you using the D or DEL against the data set? When I am in 3.4 and I use DEL I get no dialog. However, if I use D then I get it. I think it is because the delete process with D does not understand vsam and that DEL is the DEL CLUSTER command and handles it nicely. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul [EMAIL PROTECTED] Sent: Saturday, December 22, 2007 3:33 PM To: IBM-MAIN@BAMA.UA.EDU Subject: DSLIST DELETE VSAM Dialog I have long been annoyed by the dialog that ISPF DSLIST presents me for each VSAM data set present when I delete a bunch of data sets. I have no idea what it wants to know; I just press ENTER each time and sooner or later it finishes deleting the data set and moves on to the next one. Today, I deleted a bunch of data sets that HSM had migrated. I noticed to my surprise and delight that it presented no dialog to confirm or alter the deletion. I will now HMIGRATE each VSAM data set before deleting a bunch. Silicon is cheaper than carbon. Yet, I wonder: if that dialog is essential, or even important, for deleting VSAM data sets, why is it not presented alike for migrated and resident VSAM data sets? I don't think I'll start a PMR on it; if IBM chose to fix it, I'd have shot myself in the foot. -- gil -- 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: DSLIST DELETE VSAM Dialog
Lizette Koehler wrote: I think it is because the delete process with D does not understand vsam and that DEL is the DEL CLUSTER command and handles it nicely. 'D' is an ISPF line command. 'DEL' is a command unknown to ISPF and is, therefore, invoked as a TSO/E command processor with the fully qualified data set name, enclosed within apostrophes, as the one and only parameter. -- 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: DSLIST DELETE VSAM Dialog
On Sat, 22 Dec 2007 14:35:29 -0800, Edward Jaffe wrote: 'D' is an ISPF line command. 'DEL' is a command unknown to ISPF and is, therefore, invoked as a TSO/E command processor with the fully qualified data set name, enclosed within apostrophes, as the one and only parameter. -- Edward E Jaffe Not to pick nits... but ISPF certainly does special case the TSO DEL command and presents the Confirm TSO Delete dialog box if you have the Confirm Delete option selected when you invoke ISPF option 3.4 and you use DEL as a line command within ISPF 3.4. Brian -- 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: DSLIST DELETE VSAM Dialog
Brian Peterson wrote: Not to pick nits... but ISPF certainly does special case the TSO DEL command and presents the Confirm TSO Delete dialog box if you have the Confirm Delete option selected when you invoke ISPF option 3.4 and you use DEL as a line command within ISPF 3.4. True.(I forgot about that fairly recent change.) Nevertheless, the DEL command is still passed through to TSO/E. The scratch/delete operation is not performed by ISPF. -- 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
It keeps getting uglier
With the caveat that any new competition that enters the market would trigger a renewed round of privacy for any future improvements. Rather like establishing and publishing a checkpoint. Who's going to enter a market that they know they'll be thrown out of ? The VCs wouldn't think of supporting such a company. And PSI has already burnt around ten times what UMX or Fundamental burnt. Eating shoe leather (not my expression) is what they _haven't_ been doing. At the end of a working day, 3/4s of Fundamental's staff go home in the same car. Look at PSI's run rate, even without the lawyers. Rebuilding Amdahl with the air conditioning but without the revenue. IBM has pretty much replaced its architecture in the first couple of years of each decade - System/370, XA, ESA, zArchitecture. Very roughly once per decade. Next one due after z6 - 2012?. Memory sharing with Intel IA64 processors? It took the old PCMs _years_ to get established. More recently look at how long it took Fundamental - and they were using IBM's hardware and IBM's VAR chain. Seven years? Does NOT happen overnight. Hell, even working COMPLETELY within IBM, it took nearly a year to get xSeries 430 EFS TsCs agreed. 4.5 years now to run to zFuture? If z/Architecture were completely released now, PSI _might_ have a 30 month window. And that's assuming they can execute - I don't see that from their company structure, which I strongly suspect was built around the idea of doing an IPO/sale and leaving the sales/marketing to others. The loss of HP was a total disaster for PSI. HP is on every street corner in Europe - NEC has _nothing_ _like_ the dealer or support structure. It's pretty close to one office per country. PSI can't, like Fundamental did, use IBM's dealer chain - which adds to the complexity because it will need to use them to dispose of the hardware it displaces and also supply ancilliaries. Putting together a reseller chain in Europe would be several times as difficult as doing the same for Fundamental - not least because the number of target sites has halved, as had the number of potential partners. Plus the Intel processors will be unknowns for performance purposes. Things got a whole lot easier for Fundamental once I persuaded its partners to use xSeries platforms. The EU case changes a few things. I don't think there's a doctrine of unclean hands in EU law. The trade secrets business might just evaporate. I know several Amdahlers who said they were hacked off at having to sign TIDA/TILA because they'd reverse engineered most of it anyway. If PSI is right and you just have to know where to look (source for Hercules, source for z/Linux,etc.) then it's not an issue. There is no secrecy regarding patents - the whole point is to publish the discovery so you can claim it. Reading patents, of course, is dangerous and most lawyers recommend against it. Closing roads to keep them private? Yup - common in the UK. There's at least one road locally that levies a toll of 1p per person passing on Maundy Thursday. -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- 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: DSLIST DELETE VSAM Dialog
The other point to mention about migrated data sets - even VSAM components/clusters - is that their MIGRAT catalog entry is always non-VSAM, which explains why ISPF does not crank up any dialog related to VSAM deletion. Cheers, Greg P.S. Season's greetings to all. -- 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: DSLIST DELETE VSAM Dialog
- Original Message - From: Paul [EMAIL PROTECTED] [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Saturday, December 22, 2007 3:32 PM Subject: DSLIST DELETE VSAM Dialog I have long been annoyed by the dialog that ISPF DSLIST presents me for each VSAM data set present when I delete a bunch of data sets. I have no idea what it wants to know; I just press ENTER each time and sooner or later it finishes deleting the data set and moves on to the next one. Today, I deleted a bunch of data sets that HSM had migrated. I noticed to my surprise and delight that it presented no dialog to confirm or alter the deletion. I will now HMIGRATE each VSAM data set before deleting a bunch. Silicon is cheaper than carbon. Yet, I wonder: if that dialog is essential, or even important, for deleting VSAM data sets, why is it not presented alike for migrated and resident VSAM data sets? I don't think I'll start a PMR on it; if IBM chose to fix it, I'd have shot myself in the foot. Gil, I submitted a requirement to put the '/' for turning off delete confirmations for VSAM datasets and that was added to ISPF (not sure of the release, maybe z/OS V1R8). The old panel did not give you that option for VSAM, only for PS and PO datasets. The option should be there now if you're current (surely STK is running z/OS V1R9?). Regards, Tom Conley -- 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
