Re: Writing ISPF VDEFINE user exits in C
If that's the cast you need CEEPIPI. Call it once to initialize the persistent LE environment and then to call your routine with the environment token. You will have to stash away the environment token somewhere, name/token services should work. CEEPIPI will initialise me *another* LE environment though won't it? I've already got one environment, the one that my initial code is running in that then calls ISPF. I can see that CEEPIPI would help the efficiency of the user exits not having to initialise LE each time, but it doesn't allow me to connect up to the LE environment that I started with, does it? Or is there a way I can call from within an already initialised LE environment to get the environment token for the current environment that I didn't explicitly initialise, just the one that was created when I ran my main program? Maybe I'm misunderstanding? __ Information from ESET NOD32 Antivirus, version of virus signature database 4759 (20100110) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Writing ISPF VDEFINE user exits in C
On Mon, Jan 11, 2010 at 9:32 AM, Tom Quarendon tom.quaren...@teamwpc.co.ukwrote: If that's the cast you need CEEPIPI. Call it once to initialize the persistent LE environment and then to call your routine with the environment token. You will have to stash away the environment token somewhere, name/token services should work. CEEPIPI will initialise me *another* LE environment though won't it? I've already got one environment, the one that my initial code is running in that then calls ISPF. I can see that CEEPIPI would help the efficiency of the user exits not having to initialise LE each time, but it doesn't allow me to connect up to the LE environment that I started with, does it? Or is there a way I can call from within an already initialised LE environment to get the environment token for the current environment that I didn't explicitly initialise, just the one that was created when I ran my main program? Maybe I'm misunderstanding? Can you provide some type of call hierarchy diagram (labeling the various levels with Language/Run time environment used) so we can see how program flow from top to bottom? Thanks. __ Information from ESET NOD32 Antivirus, version of virus signature database 4759 (20100110) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTS - unlabeled tapes
Mark, The messages indicate that the tape was left in the insert category. Most likely your CBRUXENT entry exit has decided to 'ignore' a tape because it is not defined in the TMC. If you want the tape used despite not being defined to TMC, you need to customize the exit. Alternatively, can you define the tape to your tms? To use a tape in an IBM system managed library you must have a TCDB volume entry. You can add that using IDCAMS if the tape is already in the library and in a suitable category, or you can insert the tape and have the TCDB entry created during entry processing. Mike WoodRMM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3592 standalone drives at DR Site
When your ATL and MTL have different library names this is ok for creating new data in production/DR. But for referencing existing data you will have problems because the TCDB library location for each private volume will be atl, but in DR you want it mounted in mtl. So, you would need to alter the volume entries accordingly or look at having just 1 library defined, and using the same name, but at DR site alter the library entry to be MTL. The volcat only needs to be disconnected if you use stand-alone drives which are not system managed MTL at DR. Mike Wood RMM Development On Sat, 9 Jan 2010 13:33:18 +0800, Brian Fraser brianmfra...@gmail.com wrote: Does this sound plausible? Yes. I have both PROD DR Libraries defined in my STORAGE GROUP. Only the PROD Libraries come online and available while running in PROD, and only the DR libraries come online and available when running in DR. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RMF3 DDS (Data Portal) access of XML feeds programatically
Been there, done that, wrote the paper. My method was presented at CMG '07 as a late breaking paper. It seems that it's not in the proceedings, at least I can't find it searching the CMG archives, which is kind of annoying--presumably something to do with being a late breaking paper. It was published in the Journal in 2008, if you happen to have those back issues, but again I don't see them in electronic form on cmg.org. My technique is, as you are thinking about, JavaScript running in the browser, periodically (shortly after the RMF interval) pulling the XML from the DDS. We actually have 4 separate sysplexes, so I can pull data from all 4 sysplexes and present it on one consolidated screen. And integrate it with historical data as well. Not too difficult, and even easier if you can be allowed access to one of the common JS libraries. The negative is having to make multiple requests per interval per sysplex per user. For a few users the overhead is trivial, but I wouldn't expect my solution to scale to scores or hundreds of users. And over a slow network link it's not ideal. I'm currently thinking about writing a newer version that would use a started task (probably written in Java so it could run on a zAAP) that would do the RMF DDS queries and emit a single consolidated XML stream. In short, your idea is quite doable. If you're interested in the paper, send me a message of list and I'll get it to you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Writing ISPF VDEFINE user exits in C
Can you provide some type of call hierarchy diagram (labeling the various levels with Language/Run time environment used) so we can see how program flow from top to bottom? Thanks. C main: Declare a suitable C variable, say a char[8] Call ISPLINK to VDEFINE the variable to ISPF setting type as USER and the user exit entry point to the address of a function declared extern OS (#pragma linkage(,OS)) Call ISPLINK to do, say, TBCREATE then a TBADD. The act of doing a TBADD will require the string value of the VDEFINEd variable, hence call the user exit. In the user exit I want to call a C function to be run in the same LE environment as my main and the C function is to do the formatting of the variable (it has to access a body of code that provides the formatting services I want access to). Specifically I want the same static memory area so that global variables have the same values as they did in the C main. The user exit gets called on a separate subtask (http://www-01.ibm.com/support/docview.wss?uid=swg21023983 ), so the issue is to connect up the subtask to the original LE environment. The C main is to be run either from TSO environment interactively or from batch using the ISPSTART PGM= method. Logically, my C main calls ISPF, and ISPF calls my user exit in the same logical thread. The C main calls ISPF and blocks until ISPF returns. During that period ISPF may then call the user exit. Since the C main has blocked there is should be no issue running the user exit within the same LE environment as if it where run on the same physical thread/task as a nested function call. I want it to appear as if C main - ISPF - user exit as nested function calls. __ Information from ESET NOD32 Antivirus, version of virus signature database 4759 (20100110) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: Basic question on passing JCL set symbol to proc
There seems to be a sort of on-off switch regarding the substitution of -variables. As soon as a substituionable variable is found any variable thereafter is substituted on that card (Sic!). Regards, Thomas Berg __ Thomas Berg Specialist IT-U SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin Skickat: den 9 januari 2010 01:10 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Basic question on passing JCL set symbol to proc On Fri, 8 Jan 2010 15:15:11 -0800, Charles Mills wrote: Thanks. That works too: // SET NIL= // SET OPTS='NOTEMPL,OE,OBJ,NOARG' //* ... //COMPMAIN EXEC CBCC,CPARM=NIL'OPTS' Really!? Because the value of the operand is not _surrounded_ by apostrophes? Weird design. Indeed. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thomas Berg Sent: Thursday, January 07, 2010 5:40 AM I have as a standard a X= parm in most of my procedures (that never has a value other than null): //ANYPROC PROC X=,PARM1=,WHATEVER= . . . //STEPNEXEC PGM=ANYPGM,PARM=X'PARM1WHATEVER' . . . But (I say from the doc, without testing) in this case the X is superfluous, because one of the cases where symbols are substituted within apostrophes is the PARM of the EXEC statement. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E question
Check the SMP log for the date in question! snip Is there a way to find out all of the SYSMODs that were applied on a certain date. We are currently using SMP/E 3.4 in z/OS 1.9. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E question
On 01/10/10 04:07, âãé áï àáé wrote: Hi, Is there a way to find out all of the SYSMODs that were applied on a certain date. We are currently using SMP/E 3.4 in z/OS 1.9. TIA Gadi Like Allan said look at the SMP/E Logs. Here's an example batch job. //LISTLOG EXEC SMPE //SYSIN DD * SETBDY(TARGET) . LIST LOG(10 09 06, 10 27 06). ìùéîú ìáê, áäúàí ìðäìé äçáøä åæëåéåú äçúéîä áä, ëì äöòä, äúçééáåú àå îöâ îèòí äçáøä, îçééáéí îñîê ðôøã åçúåí òì éãé îåøùé äçúéîä ùì äçáøä, äðåùà àú ìåâå äçáøä àå ùîä äîåãôñ åáöéøåó çåúîú äçáøä. áäòãø îñîê ëàîåø (ìøáåú îñîê ñøå÷) äîöåøó ìäåãòú ãåàø àì÷èøåðé æàú, àéï ìøàåú áàîåø áäåãòä àìà îùåí èéåèä ìãéåï, åàéï ìäñúîê òìéä ìáéöåò ôòåìä òñ÷éú àå îùôèéú ëìùäé. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark Jacobs Time Customer Service Tampa, FL People assume that time is a strict progression of cause to effect... but actually, from a non-linear, non-subjective viewpoint, it's more like a big ball of wibbly-wobbly timey-wimey stuff. The Doctor - Blink -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How long does an I/O take (very roughly)?
Peter, ROTFL a cache miss will never take just 1ms. Seek and latency are still alive and well, so you are looking at 6-9ms for a read cache miss in a relatively idle system. For read cache hit a of a 4KB block will be around 0.2-0.3 ms, again in an idle system. For a write hit the copy products in use can alter the response time significantly, from a few 100ths of ms for in system copy to several ms for synchronous remote copy. Again this assumes activity on a relatively idle machine. If you are using internal SATA drives, FlashDrives, or virtualized storage there will be an even greater range of rough figures to choose from. For the original OP's purposes I would suggest 0.5ms for cache hit and 9ms for cache miss would represent numbers for 4KB blocks in a generic storage system under load. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hal Merritt Sent: Wednesday, January 06, 2010 9:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] How long does an I/O take (very roughly)? Ignoring a lot and oversimplifying, I believe that modern DASD should routinely deliver 0.1ms (hit) and 1ms (miss). -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hunkeler Peter (KIUP 4) Sent: Wednesday, January 06, 2010 10:08 AM To: IBM-MAIN@bama.ua.edu Subject: How long does an I/O take (very roughly)? Hi, I'm about to update a chart I'm using to illustrate the relative speed of various actions like CP cycle, storage access, etc. Does it still hold true that an I/O from controller cache (cache hit) takes about 1ms and and I/O from the platter (cache miss) takes about 5ms. All I want is two very rough figures. I don't want to consider different hardware or attachement types. -- Peter Hunkeler CREDIT SUISSE AG 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Software Delivery on Tape
Short version: We have not had a lot of feedback on our statement of direction to withdraw software delivery on 3480 and 3490 tape. While no news is usually good news, we want to hear from anyone who can NOT use the Internet, DVD, 3590 tape, or 3592 tape for software delivery. (Note: DVD support is planned to use a workstation that's network-attached to your z/OS system.) Please send responses to Lucy Miller (lu...@us.ibm.com) if you CANNOT use one of these options, and please tell her WHY. Details: IBM plans to discontinue delivery of z/OS software on 3480, 3480 Compressed (3480C), and 3490E tape media. IBM recommends using Internet delivery when ordering your z/OS Customized Offerings (such as ServerPac, CBPDO, Customized Offerings Driver, SystemPac®, ProductPac®) products or service, which eliminates tape handling. If you must use physical delivery, you may continue to choose 3590 or 3592 tape media (see the z/OS 1.10 Software Announcement 208-186, dated August 05, 2008). IBM intends to provide the capability to deliver the z/OS Customized Offerings and service orders on DVD media as an option for those who cannot accept 3590, 3592, and Internet delivery (see the z/OS V1.11 Software Announcement 209-242, dated August 18, 2009). This means that at some point z/OS products and service will not be available on 34xx tape media, and will only be available via 3590 and 3592 tape, Internet delivery, and DVD. We would like to understand if there are any z/OS customers that cannot accept z/OS products and service via at least one of the following: 3590 or 3592 tape, Internet, or DVD. If none of the options (Internet, DVD, or 3590 or 3592 tape) are acceptable, please contact Lucy Miller: lu...@us.ibm.com Thanks! -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Replace VTS with a tape less appliance
Hello, We have an initiative to replace our aging VTS library with a tape less appliance. In starting our research, I would like to ask the list for comments, advice, and experiences any of you may have had with tape less appliances and the conversion from VTS. Thanks for your help. Jim Weidt Jostens Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E question
Is there a way to find out all of the SYSMODs that were applied on a certain date. If you keep SMPLOG, then as suggested you can LIST LOG by date. You can LIST SYSMODS in the target zone of interest and use the INSTALLDATE subentry (written as DATE/TIME INS in SMPLIST) to identify the interesting SYSMODs. Or, you can write a program to use GIMAPI and query SYSMODs, using a FILTER like this: INSTALLDATE=yyddd. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Replace VTS with a tape less appliance
- Original Message - From: Jim Weidt james.we...@jostens.com Newsgroups: bit.listserv.ibm-main Sent: Monday, January 11, 2010 9:06 AM Subject: Replace VTS with a tape less appliance Hello, We have an initiative to replace our aging VTS library with a tape less appliance. In starting our research, I would like to ask the list for comments, advice, and experiences any of you may have had with tape less appliances and the conversion from VTS. Thanks for your help. Jim Weidt Jostens Inc. Jim, Buy lots of excess capacity. As these tapeless systems fill up, they will tend to reclaim the disk space used for each tape. So if you have a tape get scratched early, you may not be able to recover it, even if it hasn't been physically overwritten. A big drawback to these new systems. Also make sure that your scratch list is IRONCLAD. These systems will take any old scratch list and nuke the tapes. In our case, an old scratch list got passed to the box, it nuked the tapes, and the space on the box was so tight that is reclaimed the space for those tapes, even though they had not been written to. The vendor's tech support kept saying, It works just like real tape. Um, no. With real tape, I could still recover the data, thank you. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E question
- Original Message - From: גדי בן אבי gad...@malam.com Newsgroups: bit.listserv.ibm-main Sent: Sunday, January 10, 2010 4:09 AM Subject: SMP/E question Hi, Is there a way to find out all of the SYSMODs that were applied on a certain date. We are currently using SMP/E 3.4 in z/OS 1.9. TIA Gadi Gadi, Get yourself 3.5 and install it now. You'll be glad you did. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 360 programs on a z/10
On Sun, 10 Jan 2010 14:55:22 -0500, Michael Wojcik mwoj...@newsguy.com wrote: If the cook does an extraordinary job, we rarely tip him. At many better restaurants, servers are expected to share a portion of their tips with the kitchen staff. Sure - but his tips aren't related to his doing an extra special job this time. A barber raising his rates from $9 to $9.50 will get paid the same $10 as before, regardless of how good the haircut is. If it's bad, we will switch barbers. If my grandkids leave a mess at a self-service restaurant, the cleanup crew gets a tip from me. I don't see others doing that though. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Multiple dumps to SYSMDUMP
As a follow-up to last weeks discussion, I stumbled across a short document I wrote in 2006 when I was researching how this works. If anybody is interested, just drop me a note. BTW, it also contains are sample asm routines to try yourself. -- Peter Hunkeler CREDIT SUISSE AG -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 360 programs on a z/10
On 10 Jan 2010 22:30:41 -0800, Patrick Scheible k...@zipcon.net wrote: To some degree, yes. But people who carry your luggage are customarily tipped, and they're really not doing body service. I believe that's historical in nature. They didn't used to get paid at all, but were part of the labor force that hung around for opportunities to work. At one time, there were people who carried torches to walk with people in London at night (before gaslighting). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
I, too, don't see how they can be more secure. Possession is supposedly 9/10ths as the saying goes, but unless there's something bio-metric in the chip/card/human being relationship, I would have to say that the chips cards are no more, if not less, secure than the regular plastic we use today. What really peeves me is when I go into a merchant, present my plastic for my purchase and ma told I don't need to sign anything, What, no signature? But how do you know it's me? You didn't check my signature on the back of the plastic against my signature at the time of the purchase. And the merchant's cashier says that just the way it works. Personally, I try to make a mental record of where this occurs and then attempt to NEVER return there for another purchase unless it is the ONLY place to do so and then I pay cash. Can't remember the last time I was in at H^e Dp$t. (don't want to say the merchant's real name) Chuck -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, January 07, 2010 12:37 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Korean bank Moves back to Mainframes (...no, not back) That's the point of (EMV) chip cards. They are inherently more secure. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LNKLST APF Help
I like that idea. Sometimes the simplest ideas are the hardest for an old dog to recognize. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant Sent: Friday, January 08, 2010 8:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: LNKLST APF Help On Thu, 7 Jan 2010 16:05:49 -0500, Don Williams wrote: I admit it, I'm lazy. I don't like having to track the current LNKLST set name (we only IPL production 2 to 4 times a year as needed). I would like to use the same LNKLST set name that is in my PROGxx member that I used during the IPL. It could work similar to GDGs. I would backup and make my changes to our PROGxx member (member name never changes, so no update is required to IEASYSxx), do a T PROG=xx (that checks and implements my changes and I'm fairly sure that the next IPL will succeed). The new LNKLST set would be named LNKLST (or whatever name we were using), the previous one would be renamed to LNKLSTnn, such that LNKLST1 would be oldest, LNKLST2 would be next oldest, etc. Why do you need to track the current LNKLST set name? You could get the same effect if every time you updated your PROGxx you changed the name of the LNKLST by incrementing the nn or even by including the date of the change as part of the name, e.g. LNKLSTyymmdd. That could simplify your procedure by requiring only one change. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3592 standalone drives at DR Site
Hi Mike, I think we are on the same wavelengthyou describe exactly what is going through my mind. So, you would need to alter the volume entries accordingly or look at having just 1 library defined, and using the same name, but at DR site alter the library entry to be MTL. To re-cap: Option 1 - - two Libraries defined, one ATL, one MTL. - ATL comes on-line at home site, MTL comes on-line at DR site - STORAGE GROUP will list both library names - no changes to ACS routines, all allocations point to same STORAGE GROUP - at DR modify TCDB entries to point to MTL library name (how?) - CA-1 library exit needs to know about both libraries (any other implications?) Option 2 - - one library defined - use a different DR IODF with ATL devices defined as MTL devices - modify ACDS to re-define the library definition as a Manual library - any CA-1 implications ? I think Option 2 might be easier to do, but need to investigate tape management implications. Do you know if any of the RMM docs address this problem? thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3592 standalone drives at DR Site
Hi Lorne, we now use IBM DR as well, we just moved from another vendor. At this stage, our DR process is similar to yours, although I'd like to move it futher along in terms of getting closer to our real production environment. We have CA-1 up and running for stand-alone tapes, but want to replicate our tape library to make production runs as transparent as possible.See my other post at alternative ways of getting tape library transparency at DR site. thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
Well chip cards need a pin number to be entered or they don't work! And i am the only guy who knows the pin number of my card. It is not full proof but the merchant generally knows it's you because you have entered the proper pin number Or did i miss something ? Bruno Sugliani zxnetconsult(at)free(dot)fr On Mon, 11 Jan 2010 10:20:34 -0500, Hardee, Charles H charles.har...@ca.com wrote: I, too, don't see how they can be more secure. Possession is supposedly 9/10ths as the saying goes, but unless there's something bio-metric in the chip/card/human being relationship, I would have to say that the chips cards are no more, if not less, secure than the regular plastic we use today. What really peeves me is when I go into a merchant, present my plastic for my purchase and ma told I don't need to sign anything, What, no signature? But how do you know it's me? You didn't check my signature on the back of the plastic against my signature at the time of the purchase. And the merchant's cashier says that just the way it works. Personally, I try to make a mental record of where this occurs and then attempt to NEVER return there for another purchase unless it is the ONLY place to do so and then I pay cash. Can't remember the last time I was in at H^e Dp$t. (don't want to say the merchant's real name) Chuck -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
charles.har...@ca.com (Hardee, Charles H) writes: I, too, don't see how they can be more secure. Possession is supposedly 9/10ths as the saying goes, but unless there's something bio-metric in the chip/card/human being relationship, I would have to say that the chips cards are no more, if not less, secure than the regular plastic we use today. re: http://www.garlic.com/~lynn/2010.html#71 Korean bank Moves back to Mainframes (...no, not back) http://www.garlic.com/~lynn/2010.html#72 Korean bank Moves back to Mainframes (...no, not back) http://www.garlic.com/~lynn/2010.html#73 Korean bank Moves back to Mainframes (...no, not back) http://www.garlic.com/~lynn/2010.html#77 Korean bank Moves back to Mainframes (...no, not back) as previously mentioned the yes card scenario for chipcard resulted in bigger infrastructure vulnerability and more fraud than traditional magstripe. supposedly the chipcard was hard to counterfeit *AND* had two-factor authentication (chip/plastic: somthing you have and PIN: somthing you know). from three factor authentication model, misc. posts http://www.garlic.com/~lynn/subintegrity.html#3factor * something you have * something you know * something you are the assumption that multiple factor authentication is more secure than single factor is based on different authentication factors having different vulnerabilities. the problem with skimming (whether for the yes card or magstripe) ... is it is possible to have a single compromise process (end-point skimming compromise) ... invalidating the assumption about different factors having different vulnerabilities. In the case of multi-factor authentication magstripe (plastic/magstripe PIN) ... a compromised end-point skims both the magstripe information and the PIN. in the yes card scenario, a compromised end-point skims the information used by terminals to establish a valid chipcard. the crooks then install the skimmed information (similar to information skimmed for counterfeit magstripe) in a counterfeit yes card chip. once a terminal has accepted the chipcard's validation information, it then asks the chipcard 1) whether the correct PIN has been entered (a yes card always answers YES ... so it isn't necessary to even know/skim the PIN), 2) whether the transaction should be offline (YES), and 3) whether the transaction is within the account credit limit (YES). in counterfeit magstripe scenario, the account number is eventually invalidated at the backend database (and future transactions are rejected). In the counterfeit YES CARD scenario, the terminal doesn't go online to find out about any account number invalidation. the greater counterfeit YES CARD fraud is because infrastructure business rules have been moved into the chipcard (infrastructure relying on the chipcard to decide whether it is online/offline transaction and whether the transaction is within the account's credit limit). misc. past yes card posts http://www.garlic.com/~lynn/subintegrity.html#yescard one of the issues with something you are biometrics ... is that nominally biometrics information is reduced to some sort of electronic pattern for matching against value stored in backend database. If that value is compromised (analogous to something you know PIN/passwords) ... it is difficult to issue a new finger or iris. Frequently biometrics are most dependable ... when they involve secure sensors/endpoints ... that possibly are under constant surveillance by armed guards. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
Howard Brazee howard.bra...@cusys.edu writes: We probably need to go bio-metric - but this is including on-line purchases.Our current system of random, unique, not-written-down passwords does not work. re: http://www.garlic.com/~lynn/2010.html#93 Korean bank Moves back to Mainframes (...no, not back) the issue with pin/passwords aren't that they are something you know authentication ... but they are shared secrets ... some past posts http://www.garlic.com/~lynn/subintegrity.html#secrets the issue is that a unique shared secret is required for every unique security domain ... as countermeasure to cross-domain attacks (say local garage ISP and some online banking). in yes card scenario ... the PIN wasn't a shared secret ... but was between you and your chipcard. the problem was that the chipcard had the yes card vulnerability ... and so the whole infrastructure wasn't very secure. it is possible to have a something you know authentication ... w/o requiring what-ever is used ... is not shared. In the non-sharing scenario ... it would be acceptable to have the same (non-shared) something you know authentication used in multiple different security domains. something you are, biometric authentication is a problem in the online scenario ... since it can be difficult to assure secure/trusted sensor/end-point (under constant surveillance by trusted, armed guards) part of the issue is that biometric (electronic pattern recorded in backend database) is also frequently implemented as shared secret. If all biometric sensors/end-points aren't constantly secured validated ... then the recording of the biometric electronic pattern could be used to spoof a biometric reading ... by just directly transmitting the pattern. In the case of a password shared secret compromise ... the password can be replaced with new one ... fingers and iris are a little harder to replace. for a little more drift ... because of the cross-domain attack scenario, for shared secrets ... current authentication is extremely institutional-centric (unique cards passwords per security domain). In theory, a biometric shared secret implementation would require unique biometric per security domain ... modulo nobody has quite figured out how to implement such a thing. As a result, compensating procedures are required for biometric shared secrets ... like secure/trusted sensors/end-points under constant surveillance by armed guards. it is possible to design a single something you have (like a chip) and somethin you know authentication ... used in multiple different domains ... analogous to the way that same fingerprint should work in multiple different domains. part of the inhibitor to moving from institutional-centric authentication to person-centric authentication ... is when things like institutional-specific business rules are layered ontop of the authentication mechanism (like in the yes card vulnerability). In the 90s, I did quite a bit of work on AADS chip strawman for enabling migration to a person-centric authentication infrastructure (not limited just to biometrics) http://www.garlic.com/~lynn/x959.html#aads -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
charles.har...@ca.com (Hardee, Charles H) writes: What really peeves me is when I go into a merchant, present my plastic for my purchase and ma told I don't need to sign anything, What, no signature? But how do you know it's me? You didn't check my signature on the back of the plastic against my signature at the time of the purchase. re: http://www.garlic.com/~lynn/2010.html#93 Korean bank Moves back to Mainframes (...no, not back) the signature isn't a fraud countermeasure ... it is a dispute issue. if you dispute the charge and the merchant doesn't even have signed receipt ... there is nothing demonstrating that you agreed to the charge. for some low-value purchases, they've eliminated the signature requirement ... the issue is that there aren't going to be a lot of crooked consumers disputing low value charges ... and if they do ... it is trivial amount (convenience offset against crooked consumers). the infrastructure countermeasure against crooked consumers disputing large number of (unsigned) charges ... is they revoke the card. fraud countermeasure is the name on the piece of plastic and the clerk checks the name against same/similar name on some other piece of authentication (like gov. issued picture document). there was an issue in the EU at one time regarding a privacy directive ... where electronic payment cards should be as anonymous as cash at point of sale (i.e. no name on the payment card). this somewhat implied that the financial infrastructure improved the authentication mechanisms to the point that anti-fraud measures didn't require clerk matching names on multiple documents. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
Does that mean you never use self service gasoline pumps? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hardee, Charles H Sent: Monday, January 11, 2010 7:21 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Korean bank Moves back to Mainframes (...no, not back) What really peeves me is when I go into a merchant, present my plastic for my purchase and ma told I don't need to sign anything, What, no signature? But how do you know it's me? You didn't check my signature on the back of the plastic against my signature at the time of the purchase. And the merchant's cashier says that just the way it works. Personally, I try to make a mental record of where this occurs and then attempt to NEVER return there for another purchase unless it is the ONLY place to do so and then I pay cash. Can't remember the last time I was in at H^e Dp$t. (don't want to say the merchant's real name) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: y2k10 problem with credit cards in Germany
In 4b486542.2050...@t-online.de, on 01/09/2010 at 12:15 PM, Bernd Oppolzer bernd.oppol...@t-online.de said: Happy new year 200A to you all :-) Is that anything like the 19100 that one monitor displayed the year after 1999? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
In 894315.74051...@web54604.mail.re2.yahoo.com, on 01/09/2010 at 12:49 PM, Ed Gould ps2...@yahoo.com said: Either that or they are afraid that other clients will find out and it will cause a mass migration. Well, if I found out that a vendor had sued for dropping him, I would never risk leasing his software in the first place. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is there any work on z/OS ports of current OOREXX and Perl?
In listserv%201001081610259762.0...@bama.ua.edu, on 01/08/2010 at 04:10 PM, Paul Gilmartin paulgboul...@aim.com said: I heard way back that Perl was abandoning EBCDIC support in favor of Unicode. I heard the same thing, but I also saw reports of IBM work on EBCDIC support. (What can you do with EBCDIC that can't be done with Unicode?) Read files that are already in EBCDIC. If I were starting from scratch I would go with Unicode. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bad leap-year code
It is certainly true, as Joel C. Ewing contends, that bad leap-year code abounds. Unfortunately, it is also true that the assorted TM-based schemes he has presented in a sequence of posts are bad too, even radically misconceived. First, we need a definition: In the Julian calendar every fourth year is a leap year. Call this a simple first-order correction. The Gregorian calendar differs from the Julian one chiefly in introducing an dditional, second-order correction. To do so it distinguishes two classes of years, viz., o centurial years like . . . , -200, -100, 0, 100, . . . , 1800, 1900, 2000, . . . that have a serial number y such that y = 0 mod(100), and o non-centurial years, all the rest. Every fourth non-centurial Gregorian year and every fourth centurial Gregorian year are then leap years, and all the others are common or non-leap years. Cycles of days, cycles of years, and simultaneous multiple cycles of days are a standard mathematical topic. Gauss provided the definitive treatments of them, and the relevant papers are all available in the Werke, in Latin or German. Alternatively, there is a brief but eminently respectable English-language treatment of them in Dershowitz, Nachum, and Edward M. Reingold. Calendrical computations. Cambridge: Cambridge University Press, 1996, pp. 19ff and passim. Without full mastery of this material competent discussion of calendrical arithmetic is impossible, and those who have not mastered it should use the subroutine package of someone else who has to do calendrical arithmetic in just the same way and for the same reasons that engineers who need circular-function, sin, cos, and tan, values should use a subroutine package to obtain them. Calendars come in several flavors, chiefly lunar calendars like the Islamic one, lunisolar calendars like the Julian, Gregorian, and Djalali ones, and astronomical calendars like the Modern Hindu, Chinese and French Revolutionary ones. The idea that permits sense to be made out of all of them and makes date conversions among them possible is that of a day number, the representation of a date as the number of elapsed days inclusive of and following some epoch origin. (Negative day-number values, those of dates that precede an epoch origin are called proleptic ones, but this distinction is not really a very useful one; better perhaps, it is only useful for propitiating those who are suspicious of signed numbers.) Astronomers, who were the first to do serious calendrical arithmetic, represent dates as Julian Days, or JDs. JDs begin at noon and the epoch origin of the astronomical Julian calendar is the Gregorian date November 24, -4713, which is 1_721_424.5 days earlier than the epoch origin of the Gregorian Calendar, midnight, +0001 January 1. Gregorian Days, GDs, which begin at midnight, have their epoch origin on this date. The GD of midnight, December 31 is thus 0[.0]. The use of GDs permits dates about ten million years before and after this epoch origin to be represented as signed fullword values. The only proper internal representation of a date in a computer system is as a day number or the like. Using one trivializes calendrical arithmetic and eliminates leap-year calculations except in conversions. External representations of dates, those that are displayed or printed for people, must of course be in one of the [many] traditional calendrical forms; but conversion to and from day numbers and calendar dates is easy for coloro che sanno, and mandolinisti should use a subroutine package to do so. They should occupy their time in other ways. After discussing some variant TM-based schemes that operate on year numbers, Ewing ends with If the Pope and Luigi had only been astute enough to think in powers of 2 for all the corrective points, we could not only have had a much simpler algorithm but one that would remain accurate well beyond the year 10,000! I guess we should be thankful they didn't choose a much less accurate corrective point of multiple of 500 years on the grounds that 500 is simpler to express in Roman numerals than 400! This gets nothing right, and it is redeemed only a little if it is wholly jocular. The standard elucidation of the Gregorian calendar is Clavius, Christoph. Explicatio Romani calendarii a Gregorio XIII PM restituti. Romae, 1603. which is reprinted as one the five volumes of Clavius's collected mathematical works. Its is a formidable work by a formidable Jesuit scholar and observational astronomer, who was the mathematical intellect behind the new calendar, which both he and Gregory XII regarded, properly, as a revision of the Julian calendar. If you read Latin, consult it; if not let me offer my assurance that notions of representability or computational ease in roman numerals did not figure in the design of the new calendar. There are some rfetrospectively
Code Design Documentation
I have a task to create some code using OPS/MVS. I think a very long time ago I had a design document that helped me flesh out the details. IIRC - it had 3 or 4 sections. The purpose, the requirements, the what-it-does and perhaps a flow chart (as I said very old) What is being used today to help design processes. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
I disagree. The basic operation of a credit card at the get go was for the customer to be authenticated by comparing the signature on the voucher with the one on the card. If they don't match the vendor refuses the transaction. This is still the basic MO for credit card transactions. Shops like Fry's always annoy me when they ask for my Driver's license, make a cursory comparison of the picture and my name with my face and the card, and then complete the transaction without even checking the signature. Even for transactions for 1000s of dollars. Can they really spot a counterfeit license? Ron the signature isn't a fraud countermeasure ... it is a dispute issue. if you dispute the charge and the merchant doesn't even have signed receipt ... there is nothing demonstrating that you agreed to the charge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IBM Debug Tool V10 - anyone running it
Does anyone have Debug Tool V10 in production, especially for CICS COBOL? I tried V10 but went back to V9 because of issues I could not resolve. Paul P -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
I disagree. The basic operation of a credit card at the get go was for the customer to be authenticated by comparing the signature on the voucher with the one on the card. If they don't match the vendor refuses the transaction. This is still the basic MO for credit card transactions. The basic MO for buying, pre-debit card, was with signed cheques. Debit cards have PINs, and no signature required. With the potential for more money in my bank account than my credit limit, why does this make debit cards secure? PS: I'm assuming, possibly wrongly, that you don't order on the INTERNET, either. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is there any work on z/OS ports of current OOREXX and Perl?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, January 11, 2010 9:43 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Is there any work on z/OS ports of current OOREXX and Perl? In listserv%201001081610259762.0...@bama.ua.edu, on 01/08/2010 at 04:10 PM, Paul Gilmartin paulgboul...@aim.com said: I heard way back that Perl was abandoning EBCDIC support in favor of Unicode. I heard the same thing, but I also saw reports of IBM work on EBCDIC support. (What can you do with EBCDIC that can't be done with Unicode?) Read files that are already in EBCDIC. If I were starting from scratch I would go with Unicode. -- Shmuel (Seymour J.) Metz, SysProg and JOAT It needs, perhaps, to be like Java. Perl needs to read the data in and write it out using the current LOCALE, but convert it to/from Unicode as it does so. It then does all internal operations in Unicode. Perhaps this will be in Perl 6. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
On Mon, Jan 11, 2010 at 9:16 PM, Ron Hawkins ron.hawkins1...@sbcglobal.netwrote: I disagree. The basic operation of a credit card at the get go was for the customer to be authenticated by comparing the signature on the voucher with the one on the card. If they don't match the vendor refuses the transaction. This is still the basic MO for credit card transactions. Shops like Fry's always annoy me when they ask for my Driver's license, make a cursory comparison of the picture and my name with my face and the card, and then complete the transaction without even checking the signature. Even for transactions for 1000s of dollars. Can they really spot a counterfeit license? Ron the signature isn't a fraud countermeasure ... it is a dispute issue. if you dispute the charge and the merchant doesn't even have signed receipt ... there is nothing demonstrating that you agreed to the charge. Both Visa and Mastercard rules required they merchant to check the signature on the back of the card (unless it's PIN or a no-sig type of txn) and that's it. Merchants are not supposed to ask for additional identification. As Ron pointed out, it is unlikely that a clerk can spot a phony license. Also, don't forget the case where a person does not have a license, etc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
On Mon, Jan 11, 2010 at 10:20 AM, Hardee, Charles H charles.har...@ca.com wrote: I, too, don't see how they can be more secure. Possession is supposedly 9/10ths as the saying goes, but unless there's something bio-metric in the chip/card/human being relationship, I would have to say that the chips cards are no more, if not less, secure than the regular plastic we use today. What really peeves me is when I go into a merchant, present my plastic for my purchase and ma told I don't need to sign anything, What, no signature? But how do you know it's me? You didn't check my signature on the back of the plastic against my signature at the time of the purchase. And the merchant's cashier says that just the way it works. Personally, I try to make a mental record of where this occurs and then attempt to NEVER return there for another purchase unless it is the ONLY place to do so and then I pay cash. Can't remember the last time I was in at H^e Dp$t. (don't want to say the merchant's real name) Why would you blame the store for this? First, if a store has a no-signature threshold, that doesn't increase YOUR risk -- if there's an issue with a charge and there's no signature, it's not your loss. In some parts of the country, folks check signatures; where I live, they NEVER do -- and I mean NEVER. I only sign the backs of my cards because I occasionally travel to areas where they do check, and I often find that when do I get asked, the signature has worn off (that tells you how rarely it happens!). Second, credit card fraud isn't at all of interest to the banks. Credit cards make the banks *in the US* something on the order of $150B/year. Loss due to fraud is on the order of $1B/year. Wow, you say, that's a lot of money. No it isn't: loss due to card default (bankruptcy) is 20++ times that amount. This is well-documented; I remember reading over 25 years ago about someone who had documented evidence of a $400 credit card fraud, and couldn't get the bank interested in following it up -- they just wrote it off. Sometimes it's of interest to the store -- as Tony H notes, if you're buying a car, they care. That's because they're in a business where it's going to be THEIR loss if you defraud them. If I go through the McDonald's drive-thru and rip them off for a Big Mac, they probably accept the liability -- they throw out lots of food anyway. If I go through the McDonald's drive-thru and place the order from Woody Allen's _Bananas_ (1000 grilled cheese sandwiches, 300 tuna fish, 200 BLTs... yeah, I know. McD's doesn't make those, but you know what I mean) they're going to be a lot more interested in the credit card's validity. The same applies to CNP (Card-Not-Present) transactions, such as web purchases: some businesses (e.g., used books) don't even ask for the CVV (the magic 3- or 4-digit number) because their liability is low. Businesses with high liability (electronics dealers, for example) care. Note that the percentage paid by the merchant is higher for CNP transactions becaus! e of the greater potential for fraud -- that's why the local mompop restaurant may be unhappy if your card won't swipe, even though they know you and thus aren't afraid you're ripping them off. Third, don't confuse credit and debit cards. Credit cards are one thing; debit is another. If you haven't read http://www.nytimes.com/2010/01/05/your-money/credit-and-debit-cards/05visa.html?hp you really should. Fourth, Magstripe cards are easy to copy; chip-and-pin cards are (supposedly) not. So if you have a chip-and-pin card and your number is compromised, it doesn't do them any good at an ATM that takes chip-and-pin (unless they get lucky and the ATM is offline). So to some extent it's security by obscurity, but in a case where that actually makes sense and works. You need a PIN *and* the card. So it satisfies two of the four magic requirements: something you have, something you know. Biometrics can (and, I'm sure, will in the near future) add the other two: something you are, and something you do. I've heard of the YES cards, and I assume they exist, but they're not the norm yet -- cloned magstripes are. So for now, at least, chip-and-pin is more secure. As for asking for a license, sure, it doesn't guarantee anything -- but it probably stops the kid who finds a card and says Hey, let's go buy an XBOX!. So it's not entirely worthless. If you don't think it's worthwhile, then I assume you don't bother to lock your car or house -- the true professional won't be stopped by a lousy lock, eh? Hope this helps. -- ...phsiii P.S. This is actually relevant to IBM-MAIN, as the large processors use z/OS and z/TPF for transaction processing. And they all use, like, computers. So it's more on-topic than a lot of threads on here... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to
Re: Is there any work on z/OS ports of current OOREXX and Perl?
John McKown wrote on 12/01/2010 07:45:46 AM: Perhaps this will be in Perl 6. Waiting for Godot comes to mind. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
p...@voltage.com (Phil Smith) writes: I've heard of the YES cards, and I assume they exist, but they're not the norm yet -- cloned magstripes are. So for now, at least, chip-and-pin is more secure. misc. past posts mentioning YES CARD: http://www.garlic.com/~lynn/2010.html#71 Korean bank Moves back to Mainframes (...no, not back) http://www.garlic.com/~lynn/2010.html#73 Korean bank Moves back to Mainframes (...no, not back) http://www.garlic.com/~lynn/2010.html#93 Korean bank Moves back to Mainframes (...no, not back) http://www.garlic.com/~lynn/2010.html#95 Korean bank Moves back to Mainframes (...no, not back) chipcards have countermeasures for some random person taking a valid chip and extracting the necessary information ... a random person can copy magstripe information significantly easier. however, by at least the early 90s, there were cases of compromised end-points recording valid information (done during the process of valid transactions). these operations tended to be more large scale wholesale operations ... getting information for tens of thousand (or millions) ... rather than a few tens. in the end-point compromises ... the process was esssentially identical for recording magstripe information and recording chipcard authentication information (for YES CARD exploit). along the way, the criminals added wireless and other remote procedures for retrieving the skimmed/recorded information (again, little or no difference between magstripe and chipcard). part of the issue in the US was that there was fairly large scale chipcard deployment in the time-frame of cartes2002 (presentation on yes card and the yes card presentations at the ATM integrity task force meetings) ... and then evaporated w/o a trace (which may have also created some reluctance to try again). -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is there any work on z/OS ports of current OOREXX and Perl?
On Mon, 11 Jan 2010 15:45:46 -0600, McKown, John wrote: It needs, perhaps, to be like Java. Perl needs to read the data in and write it out using the current LOCALE, but convert it to/from Unicode as it does so. It then does all internal operations in Unicode. Perhaps this will be in Perl 6. Are EBCDIC code pages LOCALEs? How do I specify that my data are in CP37 and I want to use the C collating sequence, or that my data are in CP1047 and I want to use the En_US collating sequence? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
t...@harminc.net (Tony Harminc) writes: I'm not sure why this offends you so much. How would it help anything if the cashier checked your signature? Such checking is highly unreliable, and contributes much less to authentication than does the data they already know about the transaction. at one point, a large merchant looked at automatically discarding all signed receipts ... since they found that even if they automatically settled all disputes in the favor of the customer ... those dispute costs were still less than what they were paying (even in electronic from) to retain all the signed receipts. The idea was abandoned when somebody asked what might happen if the public found out that the merchant was no longer retaining the signed receipts. for the most part ... merchant associations don't like the idea of clerks having to be involved in the authentication process ... partly because they have little or no training ... partly because they have little or no authority ... and partly because clerks tend to already have more than enough to deal with. in general, merchants also don't like signature debit ... since the interchange fees (merchant discount fees, the subtracted from the total for actual paying to the merchant) are much higher there have been various disputes about the whole signature debit operation ... latest is: Best Buy Cuts off Visa Contactless with Little Risk to Sales http://www.digitaltransactions.net/newsstory.cfm?newsid=2418 above mentions problem with it being signature debit interchange fees. somewhat older article ... Study: Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit http://www.digitaltransactions.net/newsstory.cfm?newsid=738 part of the interchange fee is supposedly related to fraud level of the corresponding kind of transaction ... and there can be more than an order-of-magnitude difference (in interchange fee) between the transactions with lowest fraud and transactions with highest fraud. Past merchant class action lawsuit (sometimes referred to as the Wal-Mart case) over the high cost of signature debit cards: MasterCard Puts the 13-Year-Old Wal-Mart Case in the Rear-View Mirror http://www.digitaltransactions.net/newsstory.cfm?newsid=2256 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Replace VTS with a tape less appliance
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Monday, January 11, 2010 7:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Replace VTS with a tape less appliance Buy lots of excess capacity. As these tapeless systems fill up, they will tend to reclaim the disk space used for each tape. So if you have a tape get scratched early, you may not be able to recover it, even if it hasn't been physically overwritten. A big drawback to these new systems. Also make sure that your scratch list is IRONCLAD. These systems will take any old scratch list and nuke the tapes. In our case, an old scratch list got passed to the box, it nuked the tapes, and the space on the box was so tight that is reclaimed the space for those tapes, even though they had not been written to. The vendor's tech support kept saying, It works just like real tape. Um, no. With real tape, I could still recover the data, thank you. Regards, Tom Conley Hi Tom, Too true on your first point. The VTS we're working with just takes a VOLSER list from CA-1. On your second point, we're actively working with our vendor to provide a 7-day (configurable?) no-scratch period AFTER the VTS gets these VOLSERS from CA-1. More to come on that. Regards, Bob Lester OppenheimerFunds -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bad leap-year code
- Original Message - From: john gilmore john_w_gilm...@msn.com Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Monday, January 11, 2010 9:20 PM Subject: Re: Bad leap-year code It is certainly true, as Joel C. Ewing contends, that bad leap-year code abounds. Unfortunately, it is also true that the assorted TM-based schemes he has presented in a sequence of posts are bad too, even radically misconceived. The scheme with two TM tests works perfectly for the years 1901-2099, and nobody has claimed that it works continuously outside this range. First, we need a definition: In the Julian calendar every fourth year is a leap year. Call this a simple first-order correction. The Gregorian calendar differs from the Julian one chiefly in introducing an dditional, second-order correction. To do so it distinguishes two classes of years, viz., o centurial years like . . . , -200, -100, 0, 100, . . . , 1800, 1900, 2000, . . . that have a serial number y such that y = 0 mod(100), and This is the ISO 8601 definition, made for the modern computerized world. In the traditional proleptic calendar (both Gregorian and Julian) there was no year 0, AD 1 followed 1 BC. -Gunnar -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is there any work on z/OS ports of current OOREXX and Perl?
2010/1/11 Paul Gilmartin paulgboul...@aim.com: On Mon, 11 Jan 2010 15:45:46 -0600, McKown, John wrote: It needs, perhaps, to be like Java. Perl needs to read the data in and write it out using the current LOCALE, but convert it to/from Unicode as it does so. It then does all internal operations in Unicode. Perhaps this will be in Perl 6. Are EBCDIC code pages LOCALEs? No - a character encoding such as an EBCDIC code page is *part* of a locale. How do I specify that my data are in CP37 and I want to use the C collating sequence, or that my data are in CP1047 and I want to use the En_US collating sequence? Specify to what? If we are talking POSIX, you can define a locale of your own using localedef , and set it as the current one, using setlocale(). I'm not sure there is an en_US collating sequence, or at least one that is different from other Latin-1 languages. But it'd be something like en_US.IBM-1047.en_US. Or you can set the various POSIX environment variables like LC_COLLATE and LC_CTYPE as you like. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
Ted, I'm talking about credit cards, not debit cards. What point are you trying to make about signatures on credit cards? As for signatures on cheques, it was the responsibility of the paying Bank to verify the signatures. The person giving value was required to verify that the person with the cheque had bona fide entitlement to present it. This is different to a credit card where the merchant verifies the signature. I'm not sure what this has to do with internet purchases. Most - not all - web sites I use require the CVS number, name on the card, and address in order to verify the transaction. It's not a signature, but it falls in the category of things you know. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Monday, January 11, 2010 1:32 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Korean bank Moves back to Mainframes (...no, not back) I disagree. The basic operation of a credit card at the get go was for the customer to be authenticated by comparing the signature on the voucher with the one on the card. If they don't match the vendor refuses the transaction. This is still the basic MO for credit card transactions. The basic MO for buying, pre-debit card, was with signed cheques. Debit cards have PINs, and no signature required. With the potential for more money in my bank account than my credit limit, why does this make debit cards secure? PS: I'm assuming, possibly wrongly, that you don't order on the INTERNET, either. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
True, but the requirement to sign the slip with a signature that matches the card would be an equal deterrent. The D/L check would be redundant if the store checked the signatures in the first place. As for asking for a license, sure, it doesn't guarantee anything -- but it probably stops the kid who finds a card and says Hey, let's go buy an XBOX!. So it's not entirely worthless. If you don't think it's worthwhile, then I assume you don't bother to lock your car or house -- the true professional won't be stopped by a lousy lock, eh? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
I'm talking about credit cards, not debit cards. What point are you trying to make about signatures on credit cards? As for signatures on cheques, it was the responsibility of the paying Bank to verify the signatures. The Maybe I'm obtuse, but what is the difference in authentication for a debit or a credit card once you go to PINs? Both, at least in Canada have the EMV chip. So, my point (poorly expressed) was the fact that credit cards and debit cards now have a common exposure/protection regarding authentication. Signature for debit was done away with around 1981 (when I got my first debit card from the Royal Bank of Canada). Signature for credit card was done away with in Canada, at least, last year. And, what does a PIN/chip have to do with anything on an INTERNET purchase? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
Ron Hawkins ron.hawkins1...@sbcglobal.net True, but the requirement to sign the slip with a signature that matches the card would be an equal deterrent. The D/L check would be redundant if the store checked the signatures in the first place. Provided that the signature hasn't worn off, which it has on my most commonly used credit card. In California, a merchant is allowed to ask to see ID for a credit card purchase, but is not allowed to write down any information from that ID. http://www.privacyrights.org/fs/fs15-mt.htm As for asking for a license, sure, it doesn't guarantee anything -- but it probably stops the kid who finds a card and says Hey, let's go buy an XBOX!. So it's not entirely worthless. If you don't think it's worthwhile, then I assume you don't bother to lock your car or house -- the true professional won't be stopped by a lousy lock, eh? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bad leap-year code
Gunnar Opheim (g...@bkkfiber.no) writes This is the ISO 8601 definition, made for the modern computerized world. In the traditional proleptic calendar (both Gregorian and Julian) there was no year 0, AD 1 followed 1 BC. His point is wsell taken unexceptionable, and literally correct; but I should like to add that the astronomical Julian calendar made use of the year sequence . . . , -2, -1, 0, +1, +2, . . . at the time of its presentation by Scaliger in 1635 and has done so ever since. The absence of a zero in a calendar's year sequence marks it as a traditional--in Foucault's word, epigraphic--one, adequate to dating contracts and monuments, specifying consular or regnal intervals, recording life spans on tombstones and the like, but radically unsuitable for computation. The sequence of positive|unsigned integers is not closed under subtraction; the need for zeros in computational schemes thus long antedates computers. John Gilmore Ashland, MA 01721-1817 USA _ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/196390707/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
Jack, According to the web site you referenced they can ask for ID, but for VISA and MasterCard they cannot refuse to complete the transaction if you do not comply. I'm tempted to test this the next time I'm asked... Ron In California, a merchant is allowed to ask to see ID for a credit card purchase, but is not allowed to write down any information from that ID. http://www.privacyrights.org/fs/fs15-mt.htm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Replace VTS with a tape less appliance
Tom, Sounds like a job for Shai's VTOC Journal and Undelete. Ron written to. The vendor's tech support kept saying, It works just like real tape. Um, no. With real tape, I could still recover the data, thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bad leap-year code
On 01/11/2010 05:21 PM, Gunnar Opheim wrote: - Original Message - From: john gilmore john_w_gilm...@msn.com Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Monday, January 11, 2010 9:20 PM Subject: Re: Bad leap-year code It is certainly true, as Joel C. Ewing contends, that bad leap-year code abounds. Unfortunately, it is also true that the assorted TM-based schemes he has presented in a sequence of posts are bad too, even radically misconceived. The scheme with two TM tests works perfectly for the years 1901-2099, and nobody has claimed that it works continuously outside this range. I would have thought it was clear from the full context of this discussion that I disparaged the TM approach and only attempted to supply code in response to conjecture on the required instruction count, not as a recommendation on its use. The fact that I almost immediately had to report an error in my code re-enforces that this is an overly clever and potentially dangerous implementation choice. The same double-TM approach that works for the determining whether the lower two digits are divisible by 4 could certainly be applied to the upper two digits to determine if the century digits are divisible by 4, and thus extend this approach to correctly mirror a more conventional approach for all years in the range 1582- - but that still doesn't make it an advisable scheme to use because of the lack of clarity and the much greater difficulty of proving code correctness. -- Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bad leap-year code
On Tue, 12 Jan 2010 02:46:22 +, john gilmore wrote: The sequence of positive|unsigned integers is not closed under subtraction; the need for zeros in computational schemes thus long antedates computers. I'm not sure that matters; the sequence of year numbers can hardly be coerced to be closed. For example, if from 1912 (sinking of the Titanic) I subtract 1957 (dawn of the Space Age), I get -45 (the year Caesar proclaimed the Julian calendar). Really!? And, to make things worse: o months and days run forward in both positive and negative years. o Astronomers also use years and decimal fractions, with origin January 1, 1 BCE. So, the table (Excuse errors of a day or two): Decimal Date Month and Day Algebraic Year Customary Year 2010.34January 12 20102010 CE 1.34January 121 1 CE 0.34January 120 1 BCE -0.34 December 20 -1 2 BCE -1.34 December 20 -2 3 BCE Etc. Astronomers also divide days decimally, with origin at 0:00 of the last day of the previous month. So January spans from Jan 1.00 to Jan 31.99... Really!? 31.99 days into January? No wonder people get confused about when the century began. Sigh. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
On Mon, Jan 11, 2010 at 10:13 PM, Ron Hawkins ron.hawkins1...@sbcglobal.net wrote: Jack, According to the web site you referenced they can ask for ID, but for VISA and MasterCard they cannot refuse to complete the transaction if you do not comply. I'm tempted to test this the next time I'm asked... Be prepared not to buy whatever. Cannot may mean per VISA's rules; it doesn't mean they have to do business with you, eh? You could report them to VISA, but... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
Radoslaw, I disagree. It is not a rule; it is an agreement between the merchant and the card company. The merchants must abide by their contract with VISA or MasterCard, or they should be prepared not to business with the Credit card company, eh?. In this case cannot means exactly that: Can Not. If they complete the transaction - do business with me - then there is nothing to report. If they will not do business with me because I refuse to give an ID then the onus is on me to report them to VISA or M/C. What is really daft about Fry's in particular is that before I had a California Driver's License they would not accept my Australian Passport or my HK ID card as ID, both of which are much harder to counterfeit than a Californian Driver's license. They would only accept my Victorian Driver's License, which is not meant to be used for ID, has no security features, and can be counterfeited by anyone with a printer and a glue pot. And to top it off they still did not check the signature!!! Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of P S Sent: Monday, January 11, 2010 9:31 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Korean bank Moves back to Mainframes (...no, not back) On Mon, Jan 11, 2010 at 10:13 PM, Ron Hawkins ron.hawkins1...@sbcglobal.net wrote: Jack, According to the web site you referenced they can ask for ID, but for VISA and MasterCard they cannot refuse to complete the transaction if you do not comply. I'm tempted to test this the next time I'm asked... Be prepared not to buy whatever. Cannot may mean per VISA's rules; it doesn't mean they have to do business with you, eh? You could report them to VISA, but... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Korean bank Moves back to Mainframes (...no, not back)
On Mon, Jan 11, 2010 at 10:59 PM, Anne Lynn Wheeler l...@garlic.comwrote: t...@harminc.net (Tony Harminc) writes: I'm not sure why this offends you so much. How would it help anything if the cashier checked your signature? Such checking is highly unreliable, and contributes much less to authentication than does the data they already know about the transaction. at one point, a large merchant looked at automatically discarding all signed receipts ... since they found that even if they automatically settled all disputes in the favor of the customer ... those dispute costs were still less than what they were paying (even in electronic from) to retain all the signed receipts. The idea was abandoned when somebody asked what might happen if the public found out that the merchant was no longer retaining the signed receipts. Every state has laws regarding the retention of data related to the conduct of business. The amount of time is typically 3 to 7 years. No keeping the receipts (or copies thereof) could create legal problems as well. for the most part ... merchant associations don't like the idea of clerks having to be involved in the authentication process ... partly because they have little or no training ... partly because they have little or no authority ... and partly because clerks tend to already have more than enough to deal with. in general, merchants also don't like signature debit ... since the interchange fees (merchant discount fees, the subtracted from the total for actual paying to the merchant) are much higher there have been various disputes about the whole signature debit operation ... latest is: Best Buy Cuts off Visa Contactless with Little Risk to Sales http://www.digitaltransactions.net/newsstory.cfm?newsid=2418 above mentions problem with it being signature debit interchange fees. somewhat older article ... Study: Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit http://www.digitaltransactions.net/newsstory.cfm?newsid=738 part of the interchange fee is supposedly related to fraud level of the corresponding kind of transaction ... and there can be more than an order-of-magnitude difference (in interchange fee) between the transactions with lowest fraud and transactions with highest fraud. Past merchant class action lawsuit (sometimes referred to as the Wal-Mart case) over the high cost of signature debit cards: MasterCard Puts the 13-Year-Old Wal-Mart Case in the Rear-View Mirror http://www.digitaltransactions.net/newsstory.cfm?newsid=2256 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Replace VTS with a tape less appliance
Lester, Bob bles...@oppenheimerfunds.com wrote in message news:da46936412e1374c87478760d018a0fc01cc5...@den-xmail.den.ofi.com... -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Monday, January 11, 2010 7:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Replace VTS with a tape less appliance Buy lots of excess capacity. As these tapeless systems fill up, they will tend to reclaim the disk space used for each tape. So if you have a tape get scratched early, you may not be able to recover it, even if it hasn't been physically overwritten. A big drawback to these new systems. Also make sure that your scratch list is IRONCLAD. These systems will take any old scratch list and nuke the tapes. In our case, an old scratch list got passed to the box, it nuked the tapes, and the space on the box was so tight that is reclaimed the space for those tapes, even though they had not been written to. The vendor's tech support kept saying, It works just like real tape. Um, no. With real tape, I could still recover the data, thank you. Regards, Tom Conley Hi Tom, Too true on your first point. The VTS we're working with just takes a VOLSER list from CA-1. On your second point, we're actively working with our vendor to provide a 7-day (configurable?) no-scratch period AFTER the VTS gets these VOLSERS from CA-1. More to come on that. Regards, Bob Lester Bob, Can't you use CA-1's extended retention options for this? See Ch 1.6.3.5 Retention Options in the System Programmers Guide. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
