Re: Shark to EMC
HI, Yes, there are many ways to move data from one disk to another. Easer and a free way are to use MFNetDisk ability to copy disks to other disks without any cost and without any hardware and without any downtime for the source disks. The status of MFNetDisk is that the IBM MIDAW is under testing, and we prepare the product to production. Some of the MVS MFNetDisk parameters will be changed (SYNCDEV will be ASYNCMRR, and FstSync will be SYNCMRR). Better MFNetDisk MVS traces, Better documentation and better and faster code. Now it is the time to try the product. This is not anymore a beta product. Thanks, Shai On 1/30/08, Ron Hawkins [EMAIL PROTECTED] wrote: Tom, You can virtualise both boxes behind HDS USP-VM and mirror from Shark to EMC using TrueCopy or HUR. Ron I would think that the only way to mirror in a multi-vendor environment would be XRC. The reason is because all the replication goes through the system mover and thus is at a higher level than the bare metal. -- 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: Dumb idea - pandering to the other systems people?
My one concern would be to the future. If you were to leave, would a replacement sysprog have to relearn a new vocabulary because there is a different vocabulary in place? And since the people there don't know the Z/OS equivalents, is there a risk that the gap between what they say and what the new guy interprets could cause a major outage? For my money, the company should stump up for enough basic training to allow Z/OS discussions to be held in the appropriate language and using the appropriate terms. -- 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: TSO/REXX Does Not FREE Storage?
Not having seen the original post (did it only go to the newsfeed?), this sounds suspiciously like a problem that was reported in the early nineties and that took more than 2 or 3 years. Unfortunately for the life of me, I don't remember if it was fixed back then or if both the customer and I gave up frustrated after several years. But yes, in the case I remember storage was left until the address space terminated 878-10. That customer had provided me back then with a demo program showing the effect. Whenever it was executed, one more page was left in the address space. That was clearly visible when I dumped my own TSO user after every run. I think the storage was then gotten under the job step tcb and hence not subject to task termination. Regards, Barbara Nitz -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- 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: TSO/REXX Does Not FREE Storage?
On Wed, 30 Jan 2008 22:50:08 -0600, Joe Denison [EMAIL PROTECTED] wrote: I'm having an issue with REXX EXECs (interpreted, not compiled) that seem to *not* free storage after they terminate. Is this a known issue? Has anyone else experienced this? (my apologies for the long post -- but wanted to provide some details to reduce some questions that may be asked) A simple example to demonstrate the issue: /* REXX EXEC */ DO i=1 to 10 bb.i=COPIES(P,1000) END EXIT While running this, the used storage increases as each of the stem variables gets populated with a string of 1000 P characters. But when the REXX program terminates, the storage (GETMAIN'd) during this process does not get freed. Can you provide more details of how you're running that exec? If run via the exec command then the normal task termination should clean up all the storage. -- 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: Job ad for z/OS systems programmer trainee
On Wed, 30 Jan 2008 14:06:23 -0500, Don Leahy [EMAIL PROTECTED] wrote: On Jan 30, 2008 11:51 AM, Mark H. Young [EMAIL PROTECTED] wrote: I've read ALL the responses on this topic. In reading the job posting, the first thing that struck me was the VERY FIRST line: The purpose of the Z/OS Operating System Programmer trainee position is providing second level support on various Z/OS mainframe products amp; utilities. second level support ? As in IBM or other OEM Level 2 support?! Probably they mean level 2 support as the first level after the 'Help Desk'. That's a long way from calling IBM or other vendor for help. But someone with a good (even if non-sysprog) programming background should be able to handle it. NO, I meant level 2 support like IBM and OTHER vendors (OEM) have THEIR level 2 support (which is usually the developers, or AT LEAST some coders). Vendors' help desk is level one support, who you call in to or who read your problem ticket for the first time, and then you go to LEVEL 2. Regards, Mark -- 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
Migration from Mainframe to othre platforms - the othe bell?
Hi, I am full of reports, sent to Management, about completely succesfull conversions from the old and expensive IBM Mainframe to other platforms. And, as you may know, the most important argument is that the Mainframe is very expensive and the same level of processing, with the same degree of thrust, can be achieved in other platforms with much less money. Of course, i dont beleive this, or at least i dont think things to be so simple. So, i want to collect some information to support the Mainframe side. Are there somewhere on the web, as a counterpart of all the marketing flood about getting rid of the Mainframe, stories, reports or analysis of : - Conversions (or Consolidations) from other platforms into Mainframes. - Stories of unsuccessful migrations from Mainframe to other platforms. - Serious and independant cost analysis between different solutions. - Serious and independant studies comparing the security level of the different platforms. Thanks in advance for your help, Juan G. Mautalen El contenido del presente mensaje y sus anexos es privado, confidencial y de exclusivo uso para el titular de la direccion de correo electronico a quien esta dirigido. Puede contener informacion privilegiada o amparada por el secreto profesional o por disposiciones legales y/o reglamentarias vigentes. Cualquier modificacion, retransmision, diseminacion o divulgacion de su informacion se encuentra expresamente prohibida y su uso inadecuado puede derivar en responsabilidad civil para el usuario o configurar los delitos previstos en los articulos 153 a 157 del Codigo Penal. Si no fuere uno de los destinatarios consignados o lo hubiere recibido por error, Ud. NO ESTA AUTORIZADO a utilizar total o parcialmente, copiar, enviar, revelar, imprimir, divulgar de manera alguna el contenido del presente mensaje o el de sus adjuntos. En consecuencia, tenga a bien comunicarselo inmediatamente al emisor y ELIMINARLO. ANSES no aceptara responsabilidad alguna por errores u omisiones emergentes del presente mensaje o sus adjuntos, ni garantiza la seguridad, exactitud u oportunidad de lo transmitido por este medio debido a que el mismo puede ser objeto de intercepcion, modificacion, retraso, perdida, o bien de contener virus informaticos u otras anomalias. Asimismo, las opiniones expresadas en este mensaje son propias del remitente y no representan la opinion o politicas de ANSES y/o de ningun empleado y/o funcionario de la organizacion. Por ende, ANSES no asumira -en ningun caso- responsabilidad alguna frente al destinatario y/o terceros en virtud de dichas comunicaciones y ademas, no sera responsable frente a los usuarios por la correspondencia o los mensajes de correo electronico enviados por terceros u otras personas distintas a ANSES, ya sea que estos hubieren o no solicitado el envio de tales mensajes. ANSES se reserva el derecho de bloquear el acceso o remover en forma parcial o total todo mensaje y sus adjuntos que a su criterio pudiere resultar abusivo, difamatorio, obsceno, fraudulento, artificioso, enganoso, ofensivo o violatorio a los terminos de la presente. PD:Tildes omitidas intencionalmente. -- 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: Migration from Mainframe to othre platforms - the othe bell?
Try the following links: IBM saves $250 million consolidating Linux servers on to mainframes http://www.networkworld.com/community/node/17998 An article to counterbalance all of those we're moving off of the mainframe stories we see posted here. http://blog.coleo.com/wp-content/uploads/2007/05/share_session_9230.pdf It's a large working document. For the Business people, go to page 24 and on. z/VM strikes again:-) snip I am full of reports, sent to Management, about completely succesfull conversions from the old and expensive IBM Mainframe to other platforms. And, as you may know, the most important argument is that the Mainframe is very expensive and the same level of processing, with the same degree of thrust, can be achieved in other platforms with much less money. Of course, i dont beleive this, or at least i dont think things to be so simple. So, i want to collect some information to support the Mainframe side. Are there somewhere on the web, as a counterpart of all the marketing flood about getting rid of the Mainframe, stories, reports or analysis of : - Conversions (or Consolidations) from other platforms into Mainframes. - Stories of unsuccessful migrations from Mainframe to other platforms. - Serious and independant cost analysis between different solutions. - Serious and independant studies comparing the security level of the different platforms. Thanks in advance for your help, /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems with SNA Consoles in Z/OS V1R8
In [EMAIL PROTECTED], on 01/28/2008 at 06:24 PM, Timothy Sipples [EMAIL PROTECTED] said: Lots of products have already implemented that RFC, What RFC? As of last month it was still just an Internet draft, as far as I could tell. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TSO/REXX Does Not FREE Storage?
Joe Denison wrote: I'm having an issue with REXX EXECs (interpreted, not compiled) that seem to *not* free storage after they terminate. Is this a known issue? Has anyone else experienced this? It would be helpful if you could go at least one step beyond what you reported here to determine whether the growth that you're seeing is in a particular subpool. Subpool 78 is intentionally shared by all TSO tasks to permit storage that should persist across command and other task terminations to do so, and authorized programs have the ability to attribute storage ownership to the job step TCB for similar reasons. The identity of the subpool would cut the list of potential culprits down significantly although it would hardly point at just one. Bob Wright - MVS Service Aids -- 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
BPXAS RC=255
We had an occurrence where BPXAS on behalf of FTPD ended with a return code of 255. There were no error messages in SYSLOG or the log for BPXAS. There were no software records in Logrec. It appears that it stopped as it normally does but had this return code. Nothing appears to have failed. I know very little about this process - it just works. Our AO product caught the return code and, of course, they want an explanation. Has anyone else seen this return code or know where they are documented. I have looked on IBMLINK, Google, and IBM-Main. Help!! -- 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
More VTS Questions
I've come across a TLMS report which gives me the information needed to build my export list. I'm looking at the manuals but haven't come across what happens if the same volser shows up twice in the list...I know that the EXPORT process will sort things according to the out code..but not what it does with dupes. Not a huge deal, we can program around it but if there is no need to write extra code for this, why do it? Thanks in advance. -- 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: z890 2086-160 w/ 2 IFLs on eBay - Update
Here is the e-bay details with pictures and configuration http://cgi.ebay.com/IBM-e-SERVER-zSERIES-890-2086-A04-MAINFRAME- COMPUTER_W0QQitemZ260202032717QQihZ016QQcategoryZ64030QQssPageNa meZWDVWQQrdZ1QQcmdZViewItem -- 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: AMATERSE available (was: TSO TRANSMIT ...)
Paul Gilmartin wrote: On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote: See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS R7 and up. That's all supported releases since R6 is out of service and AMATERSE is included in z/OS R9. The PTFs closed 4 November 2007. They are: UA36927 - z/OS R7 UA36928 - z/OS R8 If you say so. But the IBM Enhanced Customer Data Repository Service page at: http://www-05.ibm.com/de/support/ecurep/mvs_create.html appears to be unaware of this. I'll try to contact them. snip I followed the link on the page you posted to the program and instructions,: and found this at that link (http://techsupport.services.ibm.com/390/trsmain.html): TRSMAIN Utility In z/OS Release 1.9 the TRSMAIN program has been added to the BCP element of z/OS, and it has been redesigned to support large format sequential data sets. This program has also been rewritten to follow IBM programming conventions. The new utility is called AMATERSE. AMATERSE is available on z/OS Releases 7 and 8 via PTFs UA36927 and UA36928 for APAR OA19194. Do you see something different? -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Job ad for z/OS systems programmer trainee
On Jan 31, 2008 8:45 AM, Mark H. Young [EMAIL PROTECTED] wrote: On Wed, 30 Jan 2008 14:06:23 -0500, Don Leahy [EMAIL PROTECTED] wrote: On Jan 30, 2008 11:51 AM, Mark H. Young [EMAIL PROTECTED] wrote: I've read ALL the responses on this topic. In reading the job posting, the first thing that struck me was the VERY FIRST line: The purpose of the Z/OS Operating System Programmer trainee position is providing second level support on various Z/OS mainframe products amp; utilities. second level support ? As in IBM or other OEM Level 2 support?! Probably they mean level 2 support as the first level after the 'Help Desk'. That's a long way from calling IBM or other vendor for help. But someone with a good (even if non-sysprog) programming background should be able to handle it. NO, I meant level 2 support like IBM and OTHER vendors (OEM) have THEIR level 2 support (which is usually the developers, or AT LEAST some coders). Vendors' help desk is level one support, who you call in to or who read your problem ticket for the first time, and then you go to LEVEL 2. Regards, Mark The position is for a bank, not a vendor. So, the use of the term Level 2 is different. My point was the job ad calls for someone with the capability of providing Level 2 support to the bank's user community, which is a very different skill set from a vendor's Level 2 support. -- 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: AMATERSE available (was: TSO TRANSMIT ...)
Paul Gilmartin wrote: On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote: See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS R7 and up. That's all supported releases since R6 is out of service and AMATERSE is included in z/OS R9. The PTFs closed 4 November 2007. They are: UA36927 - z/OS R7 UA36928 - z/OS R8 If you say so. But the IBM Enhanced Customer Data Repository Service page at: http://www-05.ibm.com/de/support/ecurep/mvs_create.html appears to be unaware of this. I'll try to contact them. The PTFs closed in July, 2007, so we're just reaching the point in time where most customers would have AMATERSE installed since those PTFs didn't qualify as emergency service. If you have TRSMAIN from the source described on that page, the data stream is compatible with AMATERSE. Bob Wright - MVS Service Aids -- 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: SPAM: How to suppress some informational VTAM messages ?
Ed and Pat, I was a VTAM old timer for a long time with 3745's , etc. I used Netview's NLDM more than NPDA. I think if my memory serves me correctly that NPDA was designed for usage with IBM modemsright ? Regards, Scott IDF -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Thursday, January 31, 2008 2:00 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SPAM: How to suppress some informational VTAM messages ? On Jan 30, 2008, at 10:41 PM, Patrick O'Keefe wrote: ... I never figured out how to make sense out of NPDA ... (Sorry about taking that quote out of order.) That isn't exactly the fault of the product (and doesn't relate to automation anyway). I was able to figure it out well enough that I've been generating my own alerts for years. As we've moved away from SNA networks there are many fewer devices and programs issuing their own alerts, but NPDA on a focal point NetView is a great central place to collect program-generated alerts notifying you of situations needing attention. Pat O'Keefe Pat: Getting back to my point NPDA was a PITA to just get a handle on what was going on. Every time I want to see some error it wasn't there. Heck half the time I had trouble finding the *** LU. I will be the first to admit I never attended a class on the thing but every time I would picked up a manual and go through the process I could not find what I was looking for. Plus as far as I could figure out there was no way to purge the database so I ended up putting it in NETVIEW at start up to delete and define the database. The splits got so bad and the pack busies got really bad (almost as much as the JES2 checkpoint) It just wasn't worth the effort to figure out how to fix it. It was easier just to bring down Netview and delete/define the data bases. For what it was designed for its probably OK but I would not recommend it (in reality AFAIK there is no other package out there) so its sort of mandatory you buy it. The network help desk could not even begin to figure it out. The only way I could get real information was to run TAF to trace items. BTW 95 percent of the time when I opened a 37xx (NCP) IBM always asked for a ACFTAP trace not what was in NPDA. The other 5 percent were extremely minor issues and I had the ACFTAF trace printed and ready to fax by the time they called back. They could could have accessed NPDA so from my perspective NPDA was essentially a waste of time. I thought I made it clear that I was not comparing netview to opsmvs. Ed 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 -- 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
AMATERSE available (was: TSO TRANSMIT ...)
On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote: See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS R7 and up. That's all supported releases since R6 is out of service and AMATERSE is included in z/OS R9. The PTFs closed 4 November 2007. They are: UA36927 - z/OS R7 UA36928 - z/OS R8 If you say so. But the IBM Enhanced Customer Data Repository Service page at: http://www-05.ibm.com/de/support/ecurep/mvs_create.html appears to be unaware of this. I'll try to contact them. Thanks, 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: DB2 queries without using MF.
Ron, With regard to AFAIK it's been a long time since RACF had any sort of special security rating, and even then you had to disconnect the network, Since z/OS 1.6 RACF has had CAPP EAL 3+ certification, and LSP EAL 3+ certification. Your above comment relates to the old DOD B1 rating that RACF, with a specific set of hardware devices and software service levels, and multi-level security (MLS, ie labeling, levels and categories) active, received in the early 90's. The old Orange Book ratings are outdated, and have been replaced by the EAL Common Criteria. For more info, see: http://www-03.ibm.com/systems/z/security/ccs_certification.html Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ron Hawkins Sent: Thursday, January 31, 2008 1:31 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DB2 queries without using MF. Lars, Then we better write off z/OS NFS right now... If Shai can provide a call to RACF via the host side client, then what is the big deal! And if you take a look around there are plenty of publicly listed companies around the world that fully comply with SOX or BASEL II, but have never owned or plan to own a MF. AFAIK it's been a long time since RACF had any sort of special security rating, and even then you had to disconnect the network Ron A product such as yours is thus unlikely to be allowed into the data center of a large (publicly traded) company or a company in the Health Care industry. -- 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: How to suppress some informational VTAM messages ?
ISTMSFLD ?? --snip-- I'm looking for the best way to suppress some informational VTAM messages in syslog. Is there anybody want to share this to me ? unsnip-- Dennis Barrett Systems Programmer Laclede Gas Co. 720 Olive Street, room 1103 St. Louis, Mo. 63101 (314) 342-0695 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 queries without using MF.
Walt, In regards to the EAL4+, that was what I remembered, but I was going by the contents of http://www-03.ibm.com/servers/eserver/zseries/zos/racf/whatsnew.html because I wanted a reference page from IBM. You may want to try and get this page updated. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Walt Farrell Sent: Thursday, January 31, 2008 10:01 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DB2 queries without using MF. On Thu, 31 Jan 2008 10:30:11 -0500, Wayne Driscoll [EMAIL PROTECTED] wrote: Since z/OS 1.6 RACF has had CAPP EAL 3+ certification, and LSP EAL 3+ certification. Thanks for mentioning that, Wayne. Just a couple of points: (1) It's z/OS (when using RACF) that has the Common Criteria certification, not RACF by itself.. (2) Since z/OS R7 we've had an evaluation at EAL4+ complying with the CAPP and LSPP protection profiles. -- Walt Farrell, CISSP IBM STSM, z/OS Security 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 -- 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: AMATERSE available (was: TSO TRANSMIT ...)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Robert Wright Paul Gilmartin wrote: On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote: See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS R7 and up. That's all supported releases since R6 is out of service and AMATERSE is included in z/OS R9. The PTFs closed 4 November 2007. They are: UA36927 - z/OS R7 UA36928 - z/OS R8 If you say so. But the IBM Enhanced Customer Data Repository Service page at: http://www-05.ibm.com/de/support/ecurep/mvs_create.html appears to be unaware of this. I'll try to contact them. The PTFs closed in July, 2007, so we're just reaching the point in time where most customers would have AMATERSE installed since those PTFs didn't qualify as emergency service. If you have TRSMAIN from the source described on that page, the data stream is compatible with AMATERSE. Any plans to assign an RSU sourceid to them? I'm reasonably sure we're not the only shop that routinely applies only RSUs, HIPERs and PEFIXes. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: AMATERSE available (was: TSO TRANSMIT ...)
I dont want AMATERSE ... I want PROFESSIONALS Paul Gilmartin wrote: On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote: See APAR OA19194, which makes AMATERSE, alias TRSMAIN, The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- 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: DB2 queries without using MF.
On Thu, 31 Jan 2008 10:30:11 -0500, Wayne Driscoll [EMAIL PROTECTED] wrote: Since z/OS 1.6 RACF has had CAPP EAL 3+ certification, and LSP EAL 3+ certification. Thanks for mentioning that, Wayne. Just a couple of points: (1) It's z/OS (when using RACF) that has the Common Criteria certification, not RACF by itself.. (2) Since z/OS R7 we've had an evaluation at EAL4+ complying with the CAPP and LSPP protection profiles. -- Walt Farrell, CISSP IBM STSM, z/OS Security 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: Dumb idea - pandering to the other systems people?
This takes me back a few years... I worked for a building society, that was eaten alive by RBS, and when I joined I was told by the person who I was going to report to for the next few years... that there are 2 Systems Prod, and 'the LPAR'(referring to the development LPAR, of course for some time I tried to convince them that both were LPAR's, but alas... He was a helpdesk person that became a NT admin, and had a good relationship with the outgoing Sysprog(upwards in the company)... In the end there were still 2 systems... Prod and 'the LPAR' I suppose it all depends it you see someone is going to continue on a steady mainframe path, then you help him to understand the terms end things the right way, but if not... by the time he is mid-level management, things like that does not matter in any case, except if Windows becomes the preferred platform for new work-loads just because he is not comfortable with the System-z, or is it Z6 from now onwards... Herbie -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of SUBSCRIBE IBM-MAIN Niall Sent: 31 Januarie 2008 10:03 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Dumb idea - pandering to the other systems people? My one concern would be to the future. If you were to leave, would a replacement sysprog have to relearn a new vocabulary because there is a different vocabulary in place? And since the people there don't know the Z/OS equivalents, is there a risk that the gap between what they say and what the new guy interprets could cause a major outage? For my money, the company should stump up for enough basic training to allow Z/OS discussions to be held in the appropriate language and using the appropriate terms. -- 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 Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- 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: AMATERSE available
Chase, John wrote: snip Any plans to assign an RSU sourceid to them? I'm reasonably sure we're not the only shop that routinely applies only RSUs, HIPERs and PEFIXes. snip http://www-03.ibm.com/support/techdocs/atsmastr.nsf/PubAllNum/Flash10106 -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: AMATERSE available (was: TSO TRANSMIT ...)
On Thu, 31 Jan 2008 10:00:18 -0600, Chase, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Robert Wright Paul Gilmartin wrote: On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote: See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS R7 and up. That's all supported releases since R6 is out of service and AMATERSE is included in z/OS R9. The PTFs closed 4 November 2007. They are: UA36927 - z/OS R7 UA36928 - z/OS R8 If you say so. But the IBM Enhanced Customer Data Repository Service page at: http://www-05.ibm.com/de/support/ecurep/mvs_create.html appears to be unaware of this. I'll try to contact them. The PTFs closed in July, 2007, so we're just reaching the point in time where most customers would have AMATERSE installed since those PTFs didn't qualify as emergency service. If you have TRSMAIN from the source described on that page, the data stream is compatible with AMATERSE. Any plans to assign an RSU sourceid to them? I'm reasonably sure we're not the only shop that routinely applies only RSUs, HIPERs and PEFIXes. It should get there soon. It has to go though CST and should wait until quarterly RSU since it isn't HIPER or resolving a PE. It was on PUT0710 so that probably means it won't hit RSU until RSU0803. 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: COBOL OUTDD(SYSOUT)
Radoslaw, In your JCL PARM specify the LE runtime option MSGFILE(yourdd), for COBOL like this: //STEP01 EXEC PGM=yourcobolprogram,PARM='yourpgmparms/MSGFILE(NEWOUTDD)' //NEWOUTDD DD SYSOUT=* I don't believe there is a way for different COBOL programs in the same LE enclave to use different OUTDD/MSGFILE names. I also don't believe that the name can be dynamically changed, but I could be mistaken about that. You'd need to check the available LE callable functions to see if there are any to do that (LE Language Reference and/or Programming Guide). HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Thursday, January 31, 2008 11:39 AM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL OUTDD(SYSOUT) The compiler option default is OUTDD(SYSOUT). Q1: Is there corresponding runtime option? Q2: Can I specify other ddname for the above in COBOL program ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w całości opłacony) wynosi 118.064.140 zł. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z dnia 21.05.2003 r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu do kwoty 118.760.528 zł. Akcje w podwyższonym kapitale zakładowym będą w całości opłacone. -- 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 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: Shark to EMC
Ron, First I wanted to say I like HDS solutions, including storage virtualization. I just wanted to complement your message, not to criticize you or HDS solutions. However you said the good news and I added the bad ones. g Regarding PPRC, etc. - yes it is paid feature, usually with capacity-based price. However virtualization does not relieve it while simply adds additional cost. Regarding SPOF in USP - I said about single point of disaster-like outage. Let's assume I have some ESS-A in location A and ESS-B in location B. I can virtualize it through USP in location A. I would need another USP in location B to be disaster-proof. Regarding to original question - in fact we don't know what are the real need and - last but not least - constraints. I mean budget and acceptable outages. I know a method for one-time migration, which is cheap (FREE), and - depending on data type - does not require longer outage than for re-IPL + few minutes. It has definitely nothing to do with USP virtualization which is good for absolutely different needs (and it is good!). Regards -- Radoslaw Skorupka Lodz, Poland Ron Hawkins wrote: Radoslaw, I think it's been two years and one generation of storage since you looked at the pricing. I don't do sales so I don't know if it is still as ugly as you make out. There are plenty of customers using it. Are you telling me that XRC is free? Or PPRC, SRDF, Flashcopy and Timefinder are free? Aren't these products licensed based on the capacity they manage. The virtualized DASD will use HUR, TrueCopy and Shasdowimage just like they were internal disks. Why should software managing external storage be free? And I did say USP-VM. I think you only looked at USP and not the diskless NSC-55, which is the -1 gen of the USP-VM. The ESS does not need any new hardware to be virtualized. The channels have to be reloaded as Fibre Channel microcode instead of FICON. If you have ESCON then you have to replace with FCP/FICON. An EMC with FICON or ESCON channels must have them replaced with Fibre Channel. Both boxes must be reformatted as Open System LUNs before they are virtualized. Please describe the single point of failure in a HDS USP-V. I'm ready to listen. I agree you get a single pane of glass management, and less moving parts. I thought this was one of the aims of risk reduction. Are you trying to tell me that if you spread your Production MVS across 10 boxes you have less risk? Tell me what happens to when you power off the one with the SYSRES, Common or the master catalog? MVS single points of failure trump any eggs in one basket syndrome. Yes I work for HDS. No I don't think virtualization is for everyone. I do think it is a solution for the original question, and possibly a better TCO solution than XRC. -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: AMATERSE available (was: TSO TRANSMIT ...)
On Jan 31, 2008 10:57 AM, John Eells [EMAIL PROTECTED] wrote: Paul Gilmartin wrote: On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote: See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS R7 and up. That's all supported releases since R6 is out of service and AMATERSE is included in z/OS R9. The PTFs closed 4 November 2007. They are: UA36927 - z/OS R7 UA36928 - z/OS R8 If you say so. But the IBM Enhanced Customer Data Repository Service page at: http://www-05.ibm.com/de/support/ecurep/mvs_create.html appears to be unaware of this. I'll try to contact them. snip I followed the link on the page you posted to the program and instructions,: and found this at that link (http://techsupport.services.ibm.com/390/trsmain.html): TRSMAIN Utility In z/OS Release 1.9 the TRSMAIN program has been added to the BCP element of z/OS, and it has been redesigned to support large format sequential data sets. This program has also been rewritten to follow IBM programming conventions. The new utility is called AMATERSE. AMATERSE is available on z/OS Releases 7 and 8 via PTFs UA36927 and UA36928 for APAR OA19194. Do you see something different? -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html It was a surprise to me when I went looking for it on my freshly installed z/OS 1.9 system and it was not there. -- Mark Pace Mainline Information Systems -- 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
COBOL OUTDD(SYSOUT)
The compiler option default is OUTDD(SYSOUT). Q1: Is there corresponding runtime option? Q2: Can I specify other ddname for the above in COBOL program ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w całości opłacony) wynosi 118.064.140 zł. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z dnia 21.05.2003 r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu do kwoty 118.760.528 zł. Akcje w podwyższonym kapitale zakładowym będą w całości opłacone. -- 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: Shark to EMC
Radoslaw, I think it's been two years and one generation of storage since you looked at the pricing. I don't do sales so I don't know if it is still as ugly as you make out. There are plenty of customers using it. Are you telling me that XRC is free? Or PPRC, SRDF, Flashcopy and Timefinder are free? Aren't these products licensed based on the capacity they manage. The virtualized DASD will use HUR, TrueCopy and Shasdowimage just like they were internal disks. Why should software managing external storage be free? And I did say USP-VM. I think you only looked at USP and not the diskless NSC-55, which is the -1 gen of the USP-VM. The ESS does not need any new hardware to be virtualized. The channels have to be reloaded as Fibre Channel microcode instead of FICON. If you have ESCON then you have to replace with FCP/FICON. An EMC with FICON or ESCON channels must have them replaced with Fibre Channel. Both boxes must be reformatted as Open System LUNs before they are virtualized. Please describe the single point of failure in a HDS USP-V. I'm ready to listen. I agree you get a single pane of glass management, and less moving parts. I thought this was one of the aims of risk reduction. Are you trying to tell me that if you spread your Production MVS across 10 boxes you have less risk? Tell me what happens to when you power off the one with the SYSRES, Common or the master catalog? MVS single points of failure trump any eggs in one basket syndrome. Yes I work for HDS. No I don't think virtualization is for everyone. I do think it is a solution for the original question, and possibly a better TCO solution than XRC. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Wednesday, January 30, 2008 11:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] Shark to EMC Ron Hawkins wrote: Tom, You can virtualise both boxes behind HDS USP-VM and mirror from Shark to EMC using TrueCopy or HUR. ...and you get single point of ...control. g But seriously - single point of disaster-like-failure. ...and you pay $s for HDS hardware and software - the software's price depends on TB of Shark and EMC. ...and you may need to buy some hardware/software features to you Shark and EMC since AFAIK (correct me if I'm wrong), the array behind the USP has to be Fibre Channel connected and FBA emulated. -- Radoslaw Skorupka Lodz, Poland -- 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: Data Erasure Products
Why not have the applications encrypt sensitive data before they write it. Seems to me that this is the logical place to protect data. DASD shredding would become an academic argument... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of SUBSCRIBE IBM-MAIN Niall Sent: Thursday, January 31, 2008 1:48 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] Data Erasure Products How about encrypting the volume in its entirety before deletion? I've been through the DR/deletion exercise a few times, and used an in- house utility to overwrite the disk. If available, however, would encryption not be a possible solution in that even if a shadow of the data were left, it should at least be in a format that is not readable? I ask because some sites may already have invested in an encryption tool, and it might be an imaginative use of an existing asset. -- 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: DFHSM ARC0184I error
Art, If these are alternate tapes this is a normal message. ThanksRick -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Art Sent: Thursday, January 31, 2008 11:08 AM To: IBM-MAIN@BAMA.UA.EDU Subject: DFHSM ARC0184I error All, I issue this command: LIST TTOC SELECT(hsm.volume) I received several of these messages: ARC0184I ERROR WHEN READING THE DFSMSHSM CONTROL DATA SET X RECORD FOR H1, RC=0004 and not figured out on how to resolve. Has anyone gotten these messages and can recommend on how to resolve. -- 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
NPDA (was: How to suppress some informational VTAM messages ?)
On Thu, 31 Jan 2008 10:31:33 -0500, Scott Ford [EMAIL PROTECTED] wrote: ... I think if my memory serves me correctly that NPDA was designed for usage with IBM modemsright ? ... One very small part of NPDA dealt with running tests on IBM modems. The basic function of NPDA is/was to display hardware-generated event data for devices in an SNA network. The format of the the event data went through several interations. I've forgotten more than I ever knew about the first 2 - RECMS and RECFMS. (Record Management Statistics and REcord Formatted Management Statistics maybe?) There are still some hooks in MVS that convert logrec OBR records to one of those. The 3rd type of event record - still actively used - is definied as part of the SNA architecture - SNA Management Services major vector x'' - ALERT which is delivered in the SNA Request Unit NMVT - Network Management Vector Transport. The Alert vector has thousands of architected code points for description possible causes recommended corrective action etc. in predefined subvectors that hardware and software use to describe exceptional conditions or resolutions from such conditions. You can think of this as the SNA equivalent of SNMP. Except the is no pretense that it is simple. And it's not limited to SNA devces. MVS's DB2 generate these alerts. So do some IBM printer abd DASD subsystems. And there is a set of user code points and the NetView GENALERT commands that lets you build your own for any situation you want. Oh. This was supposed to be about NPDA. NPDA displays this data. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: identify sas usage by component
I have not followed this thread so forgive if this was covered earlier... Speaking off the top of my head (yeah, I know, I know...) I need to leave aside the fact that any change to an OEM's SMF record requires tweaking of any vendor record specific downstream processing. If all this processing is done in-house, that's no big deal. A slight tweak to Barry's MXG record definitions, could handle that. If the data is sent to the vendor, that is easy as well. Just coble something together to reverse the changes. ... How about looking into writing an SMF Dump Program exit where you would modify the OEM SMF records on the fly and use your own record-type/sub-type numbering scheme. As the records pass through your exit, you would modify the appropriate records before they are written to the SMF dump tape/disk file. 1. If the vendor's SMF record uses a header with the SMFxSTY (subtype) field, dump a few thousand of their records to see if they actually use the STY field or is the value constant. If constant, it's possibly ripe for you to use. For this type of record, change the record type and subtype to your liking. XX for the record type and yy for sub-type for vendor yy, and zz for vendor zz and so on. 2. If the vendor's SMF record does not use a header with the SMFxSTY (subtype) field (most likely), you have two options. A. You could reformat the record header to make it support subtypes. Allocate a buffer to rebuild the record, copy the existing original 18 byte header and actual Vendor SMF record data to the appropriate area in the buffer and change the record type then insert the subtype in the SSY field to represent that specific vendor. Of course, if the vendor's record uses triplet fields, they would need to be modified as well. I would review the documentation from the vendor for this information. As for the SSI field, I would ignore it since it was never there in the first place. B. You could use the SMFxFLG field. I look at records all the time and I do not recall ever seeing a vendor actually using this field; of course YMMV. That said, I dumped a million SMF records between 128-255 they all contain the same value; 1E in my case. You could use this field for your vendor specific sub-type value and then change the record type. Of course, this will only provide you a 16:1 reduction in used records types but that's better than nothing. ;) .. Now, if one were to entertain this idea, the big question is, if multiple vendors use the same SMF record type, how does one distinguish one vendor's record from the others that are using the same record type. Generally, there is almost always some type of eye-catcher in the record that would give it away. A simple branch table/array to identify the records to process. In that table/array you could have an offset to the eye-catcher location to interrogate and another pointer to an array of values to compare against, any one of which would be a hit. JMTC... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Thursday, January 31, 2008 1:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: identify sas uage by component Bruce, Excellent point but what we found out that two many OEM programs had to be altered to do this. The only way we could do it was to split all the user SMF records off to another file (deleting them from the cumulative file. Then we ran into auditing issues and were reluctant to buck heads with the auditors. We asked the three vendors how to handle the situation they all came back with different opinions. One was to time consuming to implement as each time we got programs from them (about 3 times a year) we had to insert logic to essentially delete the smf records in question. The logic entailed changing 30 COBOL programs. In one case the other vendors were a little cleaner and they were somewhat happy to have the records deleted before it got to them but they both produced error messages that type XX were missing and the accounting people weren't happy . Another vendor's code was set to abend if they didn't get the records they were expecting. We could not win. I suppose if its a home based system it might be easier but again depending on what you are doing with them. All but one of the OEM vendor products supplied source so yes we could change it *BUT* the vendors would *NOT* support it. We thought we had tried different options and none of them made everybody happy we were in a catch 22. We tried for an exemption and they would not hear of it. The one vendor want to have the record layouts of every vendor that cut SMF records. That was sort of OK but the lead time was at least 1 year. It got so bad between the vendors and internal politics and legal (auditors) we thought of creating two master tapes but that was a nightmare as the number of tapes was depleting our tape library with just one set if we had asked for more we would have been told no in no
Re: AMATERSE available (was: TSO TRANSMIT ...)
It was a surprise to me when I went looking for it on my freshly installed z/OS 1.9 system and it was not there. Look in SYS1.MIGLIB. It's on our 1.9 system and it was on the ESP beta's long before GA. Bob Shannon Rocket Software -- 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
DFHSM ARC0184I error
All, I issue this command: LIST TTOC SELECT(hsm.volume) I received several of these messages: ARC0184I ERROR WHEN READING THE DFSMSHSM CONTROL DATA SET X RECORD FOR H1, RC=0004 and not figured out on how to resolve. Has anyone gotten these messages and can recommend on how to resolve. -- 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: AMATERSE available (was: TSO TRANSMIT ...)
Mark Pace wrote: It was a surprise to me when I went looking for it on my freshly installed z/OS 1.9 system and it was not there. Check SYS1.MIGLIB. You should find AMATERSE there with its TRSMAIN alias. MIGLIB is forced into the linklist, so you have access to it without a need for a STEPLIB. Bob Wright - MVS Service Aids -- 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
TWS HOST not reflecting FTA down
Hi all, Tivoli is great, but then again, sometime... I have searched the web, but came up with nothing for this one... We have z/890 Host and several Sun Solaris 10 FTA's Last night we had a problem where the jobs were failing with OSUF, which is understandable because the symphony file is not available because the link is down, however on the Host's TSO interface this was not reflected until after I had the OPS run a job to re-send the symphony to the FTA's. Has anyone had this problem before? I have seen a lot of the abends that we got on the web with related PQn's but not for the release we have. We have an idea why the link broke, but not why the HOST was not reflecting the change in status. Any Ideas will help. Regards Herbie Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- 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: TSO/REXX Does Not FREE Storage?
On Thu, 31 Jan 2008 13:30:12 +0100, Barbara Nitz [EMAIL PROTECTED] wrote: Not having seen the original post (did it only go to the newsfeed?), ... I see it in the archives. this sounds suspiciously like a problem that was reported in the early nineties and that took more than 2 or 3 years. Unfortunately for the life of me, I don't remember if it was fixed back then or if both the customer and I gave up frustrated after several years. This feels like a case of dueling APARs. An attempt to fix this may have had as a side efect the problem I reported in OA17169: INCORRECT STEM VARIABLE ASSIGNMENT AFTER REXX DROP FUNCTION Due to the complexity of the fix and limited impact of the error this APAR is being closed as a suggestion. This suggestion has been accepted and will be considered for inclusion in a future release or product. . The fix for this SUG APAR was shipped in the base for z/OS V1R9. ... and around we go again. -- 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: Migration from Mainframe to othre platforms - the othe bell?
Are you interested in just z/OS stories or in stories about mainframe Linux also? One big story back in 2006 was the one about Nationwide Insurance moving the processing from 400 servers to 2 IBM z900 Linux systems. At the time they estimate the savings to by $15 million over 3 years. Here is one article on it or you can Google nationwide linux to get some more. http://www.linux.com/feature/59984 Tom Kelman Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mautalen Juan Guillermo Sent: Thursday, January 31, 2008 7:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Migration from Mainframe to othre platforms - the othe bell? Hi, I am full of reports, sent to Management, about completely succesfull conversions from the old and expensive IBM Mainframe to other platforms. And, as you may know, the most important argument is that the Mainframe is very expensive and the same level of processing, with the same degree of thrust, can be achieved in other platforms with much less money. Of course, i dont beleive this, or at least i dont think things to be so simple. So, i want to collect some information to support the Mainframe side. Are there somewhere on the web, as a counterpart of all the marketing flood about getting rid of the Mainframe, stories, reports or analysis of : - Conversions (or Consolidations) from other platforms into Mainframes. - Stories of unsuccessful migrations from Mainframe to other platforms. - Serious and independant cost analysis between different solutions. - Serious and independant studies comparing the security level of the different platforms. Thanks in advance for your help, Juan G. Mautalen El contenido del presente mensaje y sus anexos es privado, confidencial y de exclusivo uso para el titular de la direccion de correo electronico a quien esta dirigido. Puede contener informacion privilegiada o amparada por el secreto profesional o por disposiciones legales y/o reglamentarias vigentes. Cualquier modificacion, retransmision, diseminacion o divulgacion de su informacion se encuentra expresamente prohibida y su uso inadecuado puede derivar en responsabilidad civil para el usuario o configurar los delitos previstos en los articulos 153 a 157 del Codigo Penal. Si no fuere uno de los destinatarios consignados o lo hubiere recibido por error, Ud. NO ESTA AUTORIZADO a utilizar total o parcialmente, copiar, enviar, revelar, imprimir, divulgar de manera alguna el contenido del presente mensaje o el de sus adjuntos. En consecuencia, tenga a bien comunicarselo inmediatamente al emisor y ELIMINARLO. ANSES no aceptara responsabilidad alguna por errores u omisiones emergentes del presente mensaje o sus adjuntos, ni garantiza la seguridad, exactitud u oportunidad de lo transmitido por este medio debido a que el mismo puede ser objeto de intercepcion, modificacion, retraso, perdida, o bien de contener virus informaticos u otras anomalias. Asimismo, las opiniones expresadas en este mensaje son propias del remitente y no representan la opinion o politicas de ANSES y/o de ningun empleado y/o funcionario de la organizacion. Por ende, ANSES no asumira - en ningun caso- responsabilidad alguna frente al destinatario y/o terceros en virtud de dichas comunicaciones y ademas, no sera responsable frente a los usuarios por la correspondencia o los mensajes de correo electronico enviados por terceros u otras personas distintas a ANSES, ya sea que estos hubieren o no solicitado el envio de tales mensajes. ANSES se reserva el derecho de bloquear el acceso o remover en forma parcial o total todo mensaje y sus adjuntos que a su criterio pudiere resultar abusivo, difamatorio, obsceno, fraudulento, artificioso, enganoso, ofensivo o violatorio a los terminos de la presente. PD:Tildes omitidas intencionalmente. -- 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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error,
Re: Shark to EMC
Radoslaw, I'm interpreting the original reference to mirroring to mean continuous replication, and not a migration exercise. In this context PAS and TDMF are solutions up to the Virtual Storage restrictions they have. For 100 volumes they will probably be OK, but for 2000 volumes you will have some challenges. XRC is an option, but you need an active mainframe, Software licenses and MIPS for the SDM at the remote site. This is not cost effective if the 2nd site is a cold site. To do replication at the storage level, Jasbir is faced with buying a new DS8K from IBM or a DMX4 from EMC, along with all the disk drives and software. Or he can use kit from resellers. He has a third option where he can buy a two diskless controllers from HDS and mirror between ESS and EMC that way. When the time comes to replace the EMC or ESS then he will not have to buy from the big three. Once virtualized the EMC DASD can be migrated to a brand new DS6K, a Clariion or a HP EVA without dropping MVS. Virtualization can improve TCO over time because the backing storage becomes a commodity and MVS users get a greater choice of storage vendor and type of storage. Is it a same day return? Maybe not. But based on a 5 year TCO covering your refresh cycle and lease/purchase choices it can be a better mousetrap. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Thursday, January 31, 2008 8:54 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] Shark to EMC Ron, First I wanted to say I like HDS solutions, including storage virtualization. I just wanted to complement your message, not to criticize you or HDS solutions. However you said the good news and I added the bad ones. g Regarding PPRC, etc. - yes it is paid feature, usually with capacity-based price. However virtualization does not relieve it while simply adds additional cost. Regarding SPOF in USP - I said about single point of disaster-like outage. Let's assume I have some ESS-A in location A and ESS-B in location B. I can virtualize it through USP in location A. I would need another USP in location B to be disaster-proof. Regarding to original question - in fact we don't know what are the real need and - last but not least - constraints. I mean budget and acceptable outages. I know a method for one-time migration, which is cheap (FREE), and - depending on data type - does not require longer outage than for re-IPL + few minutes. It has definitely nothing to do with USP virtualization which is good for absolutely different needs (and it is good!). Regards -- Radoslaw Skorupka Lodz, Poland -- 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: DB2 queries without using MF.
Wayne, Thanks for correcting me. I am a MF bigot, but I am also a realist. Do you know if z/OS with RACF is the only server/software combination that has these certification? One quick Google gave me this at the top of the page: http://www-03.ibm.com/industries/government/doc/content/news/pressrelease/10 12559109.html and this later on http://www.sun.com/smi/Press/sunflash/2005-10/sunflash.20051026.4.xml If we follow some of the arguments in this thread, if SUN get EAK4 before IBM we should jump over to Solaris as quickly as we can. My real point is that z/OS is not necessarily streets ahead in security anymore. To use this as an argument to maintain the mainframe may backfire when Solaris, AIX or HP-UX leapfrog z/OS, which I'm sure they do on occasions. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Driscoll Sent: Thursday, January 31, 2008 7:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] DB2 queries without using MF. Ron, With regard to AFAIK it's been a long time since RACF had any sort of special security rating, and even then you had to disconnect the network, Since z/OS 1.6 RACF has had CAPP EAL 3+ certification, and LSP EAL 3+ certification. Your above comment relates to the old DOD B1 rating that RACF, with a specific set of hardware devices and software service levels, and multi-level security (MLS, ie labeling, levels and categories) active, received in the early 90's. The old Orange Book ratings are outdated, and have been replaced by the EAL Common Criteria. For more info, see: http://www-03.ibm.com/systems/z/security/ccs_certification.html Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -- 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: Migration from Mainframe to othre platforms - the othe bell?
I have seen several shops get or try to get off the mainframe. The biggest reason the upper management gives for trying to get off the mainframe is no one coming out of college knows anything about the mainframe. When I was hired as a SYSPROG I had never seen a mainframe the company gave some test and asked if I wanted to learn the mainframe and I said yes. I was trained by older SYSPROGs. I am sure that is how most SYSPROGs got trained by their mentors. I have never seen a mainframe to whatever platform happen in budget or in the time frame that was sold to them. I have seen companies chunk millions at trying to get off of the mainframe when they could train the staff and exploit the mainframe for all of uses for decades. The 4 shops I know off personally that did or tried to get off the mainframe were all drive by upper management lack of understanding of the mainframe or a sales rep that came in told them they could get off the mainframe in 6 months and save them millions of dollars. What happened was what they said the cost would be multiply it by 20 to get close and if that does not drive the company into bankruptcy the added cost for all the floor space for all the servers, office space for all the additional staff to manage the server farms, and lets not forget all the extra cost of the software for every server and and every engine turned on on the server will unless they have a endless money pot. In the end I have never heard of any shop getting off of the mainframe and saving money. I don't know maybe there is savings after one or two hundred years. From: Kelman, Tom [EMAIL PROTECTED] To: IBM-MAIN@BAMA.UA.EDU Date: 01/31/2008 12:16 PM Subject: Re: Migration from Mainframe to othre platforms - the othe bell? Are you interested in just z/OS stories or in stories about mainframe Linux also? One big story back in 2006 was the one about Nationwide Insurance moving the processing from 400 servers to 2 IBM z900 Linux systems. At the time they estimate the savings to by $15 million over 3 years. Here is one article on it or you can Google nationwide linux to get some more. http://www.linux.com/feature/59984 Tom Kelman Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mautalen Juan Guillermo Sent: Thursday, January 31, 2008 7:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Migration from Mainframe to othre platforms - the othe bell? Hi, I am full of reports, sent to Management, about completely succesfull conversions from the old and expensive IBM Mainframe to other platforms. And, as you may know, the most important argument is that the Mainframe is very expensive and the same level of processing, with the same degree of thrust, can be achieved in other platforms with much less money. Of course, i dont beleive this, or at least i dont think things to be so simple. So, i want to collect some information to support the Mainframe side. Are there somewhere on the web, as a counterpart of all the marketing flood about getting rid of the Mainframe, stories, reports or analysis of : - Conversions (or Consolidations) from other platforms into Mainframes. - Stories of unsuccessful migrations from Mainframe to other platforms. - Serious and independant cost analysis between different solutions. - Serious and independant studies comparing the security level of the different platforms. Thanks in advance for your help, Juan G. Mautalen El contenido del presente mensaje y sus anexos es privado, confidencial y de exclusivo uso para el titular de la direccion de correo electronico a quien esta dirigido. Puede contener informacion privilegiada o amparada por el secreto profesional o por disposiciones legales y/o reglamentarias vigentes. Cualquier modificacion, retransmision, diseminacion o divulgacion de su informacion se encuentra expresamente prohibida y su uso inadecuado puede derivar en responsabilidad civil para el usuario o configurar los delitos previstos en los articulos 153 a 157 del Codigo Penal. Si no fuere uno de los destinatarios consignados o lo hubiere recibido por error, Ud. NO ESTA AUTORIZADO a utilizar total o parcialmente, copiar, enviar, revelar, imprimir, divulgar de manera alguna el contenido del presente mensaje o el de sus adjuntos. En consecuencia, tenga a bien comunicarselo inmediatamente al emisor y ELIMINARLO. ANSES no aceptara responsabilidad alguna por errores u omisiones emergentes del presente mensaje o sus adjuntos, ni garantiza la seguridad, exactitud u oportunidad de lo transmitido por este medio debido a que el mismo puede ser objeto de intercepcion, modificacion, retraso, perdida, o bien de contener virus informaticos u otras anomalias. Asimismo, las opiniones expresadas en este mensaje son propias del remitente y no representan la opinion o politicas de ANSES y/o de ningun empleado y/o
Re: Shark to EMC
HI, Now you can download the new MFNetDisk with the support of MIDAW. Some of the people assume that this product is a toy, OK but it can do all the important tasks of EMC, HDS and IBM disk and also some tasks of backup (in the PC), DR in no time, mirroring to any real disk (EMC, HDS and IBM), 3390 emulations, replace of OEM real disk with another OEM without downtime or performance degradation, incremental track backup (track no file!), Sharing 3390 disks among MF and MF emulation, sharing 3390 from any distance without any hardware, PC API do read MVS file from PC Server from any PC without any MVS involvement and more. The bitmap file MPCLOG RECFM is changed from RECFM=U to RECFM=F. Action is required. More information in the FIXINFO file in my site. Thanks, Shai On 1/31/08, shai hess [EMAIL PROTECTED] wrote: HI, Yes, there are many ways to move data from one disk to another. Easer and a free way are to use MFNetDisk ability to copy disks to other disks without any cost and without any hardware and without any downtime for the source disks. The status of MFNetDisk is that the IBM MIDAW is under testing, and we prepare the product to production. Some of the MVS MFNetDisk parameters will be changed (SYNCDEV will be ASYNCMRR, and FstSync will be SYNCMRR). Better MFNetDisk MVS traces, Better documentation and better and faster code. Now it is the time to try the product. This is not anymore a beta product. Thanks, Shai On 1/30/08, Ron Hawkins [EMAIL PROTECTED] wrote: Tom, You can virtualise both boxes behind HDS USP-VM and mirror from Shark to EMC using TrueCopy or HUR. Ron I would think that the only way to mirror in a multi-vendor environment would be XRC. The reason is because all the replication goes through the system mover and thus is at a higher level than the bare metal. -- 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: Timeout to server printer software after IP change
Thanks to everyone who replied on and off list. We've been looking at all the suggestions. Now it looks like we may have a resolution. One of our server guys has been working with McKesson on the problem. Yesterday they found a 4 gig log file on the server that bothered them. They renamed the log file and made a new one. We stayed in communication all night with the server and everyone's reports were ready this morning. I'll still be keeping my fingers crossed for a few days. Quite a coincidence that we start having this problem the night we converted to 1.7 with IBM TCPIP, huh? Thanks again to a great bunch of folks... Robert Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Migration from Mainframe to othre platforms - the othe bell?
Training employees works when the expectation by both employers and employees is for career employees. Both sides need to favor the long term over the short term. Training a workplace works when expectation by both tax-payers and tax-beneficiaries is long term. When politicians and voters are more concerned with the near term, big deficits are preferred over preparing the next generation. It's not just mainframe users that are concerned only with now. -- 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
Common Criteria security (was: DB2 queries without using MF.)
Ron, I also am an MF bigot, but also realize that we live in a wide world, and that far too many people who should know better sometimes have a tendency to view the IT world as z/OS vs Windows, when in reality there are a lot of UNIX servers that are approaching in many ways, and surpassing in others, the mainframe. As for security, since z/OS with RACF has had EAL 3+ since 1.6 and (as Walt Farrell pointed out) has had EAL 4+ since 1.7, I would assume that CA is working on this, but I have no knowledge either way. Also, I do not know if IBM has submitted any version of RACF for z/VM for certification. Also, one must keep in mind that just because the base operating system and security system has been certified as EAL 4+ (or whatever), it doesn't mean that it isn't possible (or even difficult) to configure the system in a very unsecure fashion. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ron Hawkins Sent: Thursday, January 31, 2008 12:29 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DB2 queries without using MF. Wayne, Thanks for correcting me. I am a MF bigot, but I am also a realist. Do you know if z/OS with RACF is the only server/software combination that has these certification? One quick Google gave me this at the top of the page: http://www-03.ibm.com/industries/government/doc/content/news/pressreleas e/10 12559109.html and this later on http://www.sun.com/smi/Press/sunflash/2005-10/sunflash.20051026.4.xml If we follow some of the arguments in this thread, if SUN get EAK4 before IBM we should jump over to Solaris as quickly as we can. My real point is that z/OS is not necessarily streets ahead in security anymore. To use this as an argument to maintain the mainframe may backfire when Solaris, AIX or HP-UX leapfrog z/OS, which I'm sure they do on occasions. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Driscoll Sent: Thursday, January 31, 2008 7:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] DB2 queries without using MF. Ron, With regard to AFAIK it's been a long time since RACF had any sort of special security rating, and even then you had to disconnect the network, Since z/OS 1.6 RACF has had CAPP EAL 3+ certification, and LSP EAL 3+ certification. Your above comment relates to the old DOD B1 rating that RACF, with a specific set of hardware devices and software service levels, and multi-level security (MLS, ie labeling, levels and categories) active, received in the early 90's. The old Orange Book ratings are outdated, and have been replaced by the EAL Common Criteria. For more info, see: http://www-03.ibm.com/systems/z/security/ccs_certification.html Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -- 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: Shark to EMC
Now you can download the new MFNetDisk with the support of MIDAW. Maybe, I'm too picky. But, all I've seen from this poster is stuff about the product. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Data Erasure Products
On Jan 31, 2008, at 3:48 AM, SUBSCRIBE IBM-MAIN Niall wrote: How about encrypting the volume in its entirety before deletion? I've been through the DR/deletion exercise a few times, and used an in-house utility to overwrite the disk. If available, however, would encryption not be a possible solution in that even if a shadow of the data were left, it should at least be in a format that is not readable? I ask because some sites may already have invested in an encryption tool, and it might be an imaginative use of an existing asset. I vaguely remember a story here I cannot remember where I heard it (it may be an urban legend). *SUPPOSEDLY* the CIA (NSA??) was able to read a disk even after data has been written on it, even after 10 or 11 times. I have heard this but where? I do *NOT* know if this is true or not. 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
Re: Data Erasure Products
I have used FDR Erase. It is easy to install and use. We last used it after a DR test. Not too expensive. Pat Mihalec Rush University Medical Center Senior System Programmer (312) 942-8386 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Job ad for z/OS systems programmer trainee
On Jan 31, 2008, at 7:45 AM, Mark H. Young wrote: ---SNIP- NO, I meant level 2 support like IBM and OTHER vendors (OEM) have THEIR level 2 support (which is usually the developers, or AT LEAST some coders). Vendors' help desk is level one support, who you call in to or who read your problem ticket for the first time, and then you go to LEVEL 2. Regards, Mark Mark, a *LONG* time ago early 1990's I interviewed for a job out in California that was well to say the least different. This was a systems programmer job that was at a data center that worked with top secret data. You were expected to debug vendor code yet not talk with the vendor. I asked for details and they basically said you were expected to find the bug and fix it yourself without calling the vendor (even IBM). I practically ran from the job. 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
Re: Data Erasure Products
On Jan 31, 2008, at 3:48 AM, SUBSCRIBE IBM-MAIN Niall wrote: How about encrypting the volume in its entirety before deletion? I've been through the DR/deletion exercise a few times, and used an in-house utility to overwrite the disk. If available, however, would encryption not be a possible solution in that even if a shadow of the data were left, it should at least be in a format that is not readable? I ask because some sites may already have invested in an encryption tool, and it might be an imaginative use of an existing asset. I vaguely remember a story here I cannot remember where I heard it (it may be an urban legend). *SUPPOSEDLY* the CIA (NSA??) was able to read a disk even after data has been written on it, even after 10 or 11 times. I have heard this but where? I do *NOT* know if this is true or not. Ed I have worked at several top secret installations in the past and I was told that they take the old DASD and drop them in a acid bath then cut them up. Never saw it happened so not totally sure it was done or not. George Fogg -- 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: Job ad for z/OS systems programmer trainee
Well, all us write in our resumes that we look for a challenge. From that position profile, I can't think of anything more challenging. :) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Thursday, January 31, 2008 3:07 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Job ad for z/OS systems programmer trainee Mark, a *LONG* time ago early 1990's I interviewed for a job out in California that was well to say the least different. This was a systems programmer job that was at a data center that worked with top secret data. You were expected to debug vendor code yet not talk with the vendor. I asked for details and they basically said you were expected to find the bug and fix it yourself without calling the vendor (even IBM). I practically ran from the job. 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
Fw: COBOL OUTDD(SYSOUT)
I see nothing at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG32/2.4.39 that says that you can't have different OUTDD values for different programs within a single load module (or dynamic call sequence). If you want the specific DD to be in the program, add a Process Outdd(whatever) before your identification division of each program that you want to use myfile. Farley, Peter x23353 [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Radoslaw, In your JCL PARM specify the LE runtime option MSGFILE(yourdd), for COBOL like this: //STEP01 EXEC PGM=yourcobolprogram,PARM='yourpgmparms/MSGFILE(NEWOUTDD)' //NEWOUTDD DD SYSOUT=* I don't believe there is a way for different COBOL programs in the same LE enclave to use different OUTDD/MSGFILE names. I also don't believe that the name can be dynamically changed, but I could be mistaken about that. You'd need to check the available LE callable functions to see if there are any to do that (LE Language Reference and/or Programming Guide). HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Thursday, January 31, 2008 11:39 AM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL OUTDD(SYSOUT) The compiler option default is OUTDD(SYSOUT). Q1: Is there corresponding runtime option? Q2: Can I specify other ddname for the above in COBOL program ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl -- 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: Data Erasure Products
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pat Mihalec Sent: Friday, 1 February 2008 7:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Data Erasure Products I have used FDR Erase. It is easy to install and use. We last used it after a DR test. Not too expensive. Pat Mihalec Rush University Medical Center Senior System Programmer (312) 942-8386 [EMAIL PROTECTED] Just to let people know, Innovation Data Processing's FDRERASE/OPEN has just now acquired formal CCEVS accreditation with a conformance claim of EAL2 Augmented with ALC_FLR.2 . The details of the validation can be viewed at the following link: http://niap-ccevs.org/cc-scheme/st/index.cfm/vid/10232 For those who are interested, the CCEVS accreditation details for the existing FDRERASE for z/OS can be viewed at the following link: http://niap-ccevs.org/cc-scheme/st/index.cfm/vid/10064 Stephen Mednick Computer Supervisory Services Sydney, Australia -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New Opcodes
On Fri, 25 Jan 2008 13:12:22 -0800, Keith E. Moe wrote: Second, there was one mnemonic that caught my eye. I do not know what it does, but it's probably one that none of us will forget: PTF. Are you certain that it wasn't PTFF (which was already described in the current Principles of Operations -05 pub)? If so there's no NDA worries. I'm still waiting for MVCOS to finally make it out into the PoO... it was leaked pretty thoroughly a few SHAREs ago in several IBM sessions but didn't make it into either of the last 2 PoOs. (I don't care about what issues caused it to be late, I just want it to be born after all this time.) -- Tom Schmidt -- 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: COBOL OUTDD(SYSOUT)
I stand corrected. OUTDD and MSGFILE are not related at all, and indeed there seems to be no prohibition nor error in specifying different OUTDD ddnames for different COBOL programs in the same enclave. I just tested a simple main program and subprogram with different OUTDD values at compile time and unique DISPLAY statements, and both DD's were properly written to, and the LE MSGFILE output (via PARM='/RPTOPTS(ON),MSGFILE(CEEMSG)') went to a third DD, with no affect on the COBOL OUTDD's at all. Ya learn somthin' new every day... Ain't it grand? Thanks. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Thursday, January 31, 2008 3:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Fw: COBOL OUTDD(SYSOUT) I see nothing at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG32/2.4. 39 that says that you can't have different OUTDD values for different programs within a single load module (or dynamic call sequence). If you want the specific DD to be in the program, add a Process Outdd(whatever) before your identification division of each program that you want to use myfile. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: Migration from Mainframe to othre platforms - the othe bell?
I think I've mentioned this here before, but I used to work at PH Mining Equipment in Milwaukee. They had a mainframe running SAP/R2, and several other applications. It was an MP3000-H50. In the mid 90's, they bought Joy Mining in Pennsylvania. Joy converted their old 3081 to an Lpar on our machine in Milwaukee back in 1996. A few years later, Joy decided they didn't want to go through a Y2K conversion, and still have all old software. They converted everything to SAP/R3, and got off our mainframe in early 1999. When SAP said that if we ran PH on the same equipment that Joy was using, they would not charge us for new SAP licenses. This eliminated a huge cost, and PH decided to convert to SAP/R3 and run it in Pennsylvania. The project took just under 2 years when it finally got started till they turned the mainframe off. There was some pain at first, but the conversion as a whole went very well. According to management, they saved a bundle of money not having to pay for 2 datacenters, no z/OS software and hardware, etc. Eleven people, including myself and my boss were eliminated, although one retired, and a couple found jobs within the company. One of those people got a job at higher pay as a forklift operator! You can get off the mainframe and save money! Having a company with a datacenter already set up and running was a big help though. I'm sure that had that not been the case, it would have taken at least a year or so more time to convert. Eric Michael Saraco [EMAIL PROTECTED] wrote: In the end I have never heard of any shop getting off of the mainframe and saving money. I don't know maybe there is savings after one or two hundred years. -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- 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: Migration from Mainframe to othre platforms - the othe bell?
Hey, that's great news! I used to run a forklift... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Eric Bielefeld Sent: Thursday, January 31, 2008 3:54 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Migration from Mainframe to othre platforms - the othe bell? SNIP One of those people got a job at higher pay as a forklift operator! You can get off the mainframe and save money! Having a company with a datacenter already set up and running was a big help though. I'm sure that had that not been the case, it would have taken at least a year or so more time to convert. Eric Michael Saraco [EMAIL PROTECTED] wrote: In the end I have never heard of any shop getting off of the mainframe and saving money. I don't know maybe there is savings after one or two hundred years. -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- 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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.17/1253 - Release Date: 1/31/2008 9:09 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.17/1253 - Release Date: 1/31/2008 9:09 AM -- 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: Data Erasure Products
-Original Message- Ed I have worked at several top secret installations in the past and I was told that they take the old DASD and drop them in a acid bath then cut them up. Never saw it happened so not totally sure it was done or not. George Fogg Physical destruction of DASD such as that described by George is probably the purest form of data destruction. However, if my understanding of the various compliance requirements is correct, it would need to be witnessed by someone from the owning organisation in order to provide formal verification. The downside of physically destroying the media as against using a certified erase solution to remove the contents is that the obsolete storage media can never be acquired on a lease-basis given that the box is not going to be able to be returned intact when the lease would have expired. For storage subsystems that have been purchased, there's no way that any residual value that the box might contain can be realised. Using a secure storage santisation or overwriting methodology, once the data has been removed, it's then possible to put out requests to second hand equipment dealers to submit an offer to acquire the box and remove it and at least get some dollars back. Stephen Mednick Computer Supervisory Services Sydney, Australia -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BPXAS RC=255
What a coincidence. We IPLed a sandbox system this morning and saw a similar problem with SSHD. It appeared to us that OMVS had not yet fully initialized. Automation complained about SSHD, and several minutes later it was (re)started manually with no problem. The original return code 255 may just be a simple-minded representation of the -1 that Unix is famous for. Our case plus the FTPD case has made us rethink the trigger for OMVS-dependent tasks. For whatever reason, we have historically triggered some of these tasks on TCP/IP initialization. But IP seems to come up earlier than it used to--this was a 1.9 system. We're now looking at triggering on this message: BPXI004I OMVS INITIALIZATION COMPLETE . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] John Hooper [EMAIL PROTECTED] .COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU BPXAS RC=255 01/31/2008 07:27 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU We had an occurrence where BPXAS on behalf of FTPD ended with a return code of 255. There were no error messages in SYSLOG or the log for BPXAS. There were no software records in Logrec. It appears that it stopped as it normally does but had this return code. Nothing appears to have failed. I know very little about this process - it just works. Our AO product caught the return code and, of course, they want an explanation. Has anyone else seen this return code or know where they are documented. I have looked on IBMLINK, Google, and IBM-Main. Help!! -- 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
VLF - What's in your VLF
What are the entries in your VLF that give your system a big performance boost? John Norgauer University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VLF - What's in your VLF
What are the entries in your VLF that give your system a big performance boost? Class names CSVLLA, IKJEXEC, IGGCAS, and for RACF, IRRGTS, IRRACEE, IRRGMAP, IRRUMAP and IRRSMAP. George Fogg -- 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: Migration from Mainframe to othre platforms - the othe bell?
It was true back in the 90's that the mainframe was more expensive for most customers. I actually disagree with that. Back then, PCs and *NIX platforms were a lot more expensive. If you looked at cost per seat, and cost for support personell, the M/F was still cheaper. The whole TCO argument has always been political. In the PC/NIX world manpower is rarely counted. It in on the M/F. Also, BSOD resolution by the end-user is never counted, nor any of the extra work the user and the help desk does is never counted. Rarely does a business (CICS) user under z/OS have to call for technical problems. Under the others, most are technical. And, the windows solution? Re-Image. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFHSM ARC0184I error
Rick Dave, I can not locate the tape to know what the dataset or for that matter if its really a alternate tape a migrated tape.. etc. In my search I have two other tapes that are prefixed with H** and took care of those but can not find the others.. If you know of anything else that I can try and/or look for. Please let me know. Thank you in Advance -- 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: Data Erasure Products
Unless there is some weird legislative standard which says that encryption is fine for transmission of data over open IP networks, but is not fine for resundant data held on permanent storage. I'm interpreting this from a Canadian perspective, but after working for a company headquartered in the US, I don't believe there are any legislative standards. SOX, et al, say you have to protect your data. They don't say how, since they are not IT professionals. It's up to your: SME's Compliance officers And, auditors -- external and internal. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Migration from Mainframe to othre platforms - the othe bell?
I'd suggest that you do a seach on mainframe TCO on Google to get some more information on this topic. I spend a lot of time at IBM educating customers on what the true cost of ownership is for various technology platforms they choose. It was true back in the 90's that the mainframe was more expensive for most customers. Not true today where the mainframe can be competitive or cheaper than other platforms, of course depending on your own specific situation and software. Since I do this, I can probably also find a coworker of mine to run a TCO study for your site. I can be reached directly at [EMAIL PROTECTED] Dan On Jan 31, 2008 1:53 PM, Eric Bielefeld [EMAIL PROTECTED] wrote: I think I've mentioned this here before, but I used to work at PH Mining Equipment in Milwaukee. They had a mainframe running SAP/R2, and several other applications. It was an MP3000-H50. In the mid 90's, they bought Joy Mining in Pennsylvania. Joy converted their old 3081 to an Lpar on our machine in Milwaukee back in 1996. A few years later, Joy decided they didn't want to go through a Y2K conversion, and still have all old software. They converted everything to SAP/R3, and got off our mainframe in early 1999. When SAP said that if we ran PH on the same equipment that Joy was using, they would not charge us for new SAP licenses. This eliminated a huge cost, and PH decided to convert to SAP/R3 and run it in Pennsylvania. The project took just under 2 years when it finally got started till they turned the mainframe off. There was some pain at first, but the conversion as a whole went very well. According to management, they saved a bundle of money not having to pay for 2 datacenters, no z/OS software and hardware, etc. Eleven people, including myself and my boss were eliminated, although one retired, and a couple found jobs within the company. One of those people got a job at higher pay as a forklift operator! You can get off the mainframe and save money! Having a company with a datacenter already set up and running was a big help though. I'm sure that had that not been the case, it would have taken at least a year or so more time to convert. Eric Michael Saraco [EMAIL PROTECTED] wrote: In the end I have never heard of any shop getting off of the mainframe and saving money. I don't know maybe there is savings after one or two hundred years. -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- 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 -- READ CAREFULLY. By reading this email, you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (BOGUS AGREEMENTS) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Data Erasure Products
I've heard from my Amdahl days that the decommissioned machines had to be destroyed rather than returned for their parts value - and that the destruction was pretty definitive. But none of these anecdotes answer my question: would you feel happy after, for instance, a DR test, to know that the DASD you used contained only encrypted data and that the VTOC's had been overwritten? More importantly, would this ensure compliance with the standards required? I ask because ther seems to be a couple of contradictory issues involved: in some jurisdictions a standard of encryption is considered to be a requirement when sending data offsite, be it over the wires or in some other portable format. In other words, the authorities accept that once it has been encrypted and adeqaute care is taken over key exchange, then you have fulfilled the requiremnts to protect your data. Yet deleted data seems to require another standard - or does it? In the same vein, if you are decommisioning DASD, or removing yourself from a hot-site, would encrypting your data be adequate both to satisy compliancy requirements and to make you feel comfortable yourelves? I assume the re-init at the least of the volumes afterwards, of course. Even the entries of a VTOC could be valuable. I'd be interested to se what the Innovation Data Processing people would have to say on this as they provide both encryption and erase products. One of them - short of huge performance factors which wouldn't really be an issue when decommisioning DASD- would appear to be redundant. Unless there is some weird legislative standard which says that encryption is fine for transmission of data over open IP networks, but is not fine for resundant data held on permanent storage. -- 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
Metal C
I was looking forward to this, but now that I've found a little time to play with it, I am a little puzzled. There are options METAL and GENASM, and the doc says that METAL forces GENASM, but when I try GENASM without METAL, I get CCN0458(S) Option GENASM is invalid because option METAL is not specified. [Talk about a good error message - the explanation for CCN0458 says: Explanation: The option 1 is only valid when used in conjunction with 2. In the message text: 1 and 2 are both option names. User Response: Compile with 2 or remove 1.] So what is GENASM for if it can't be specified by itself? Then it seems that METAL inhibits use of the ARCH option, so METAL C must generate code at the ARCH(CURRENT) level, which means it can (and does) use LARL and the like from the long displacement facility. Well, no, actually it accepts ARCH(5), which says is the default and generates code at the z900/z800 level, but it still generates LARL, which I don't believe is architected at that level. Anyway - there are plenty of other things to ask about, but I'm not sure where the right place is. I don't think there's a System z C/C++ list... Are other people actively using Metal C? I'd be interested in your experiences. Tony H. -- 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: Data Erasure Products
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of SUBSCRIBE IBM-MAIN Niall Sent: Friday, 1 February 2008 10:16 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Data Erasure Products SNIP But none of these anecdotes answer my question: would you feel happy after, for instance, a DR test, to know that the DASD you used contained only encrypted data and that the VTOC's had been overwritten? More importantly, would this ensure compliance with the standards required? I ask because ther seems to be a couple of contradictory issues involved: in some jurisdictions a standard of encryption is considered to be a requirement when sending data offsite, be it over the wires or in some other portable format. In other words, the authorities accept that once it has been encrypted and adeqaute care is taken over key exchange, then you have fulfilled the requiremnts to protect your data. Yet deleted data seems to require another standard - or does it? In the same vein, if you are decommisioning DASD, or removing yourself from a hot-site, would encrypting your data be adequate both to satisy compliancy requirements and to make you feel comfortable yourelves? I assume the re-init at the least of the volumes afterwards, of course. Even the entries of a VTOC could be valuable. SNIP Your idea would appear to have some merit but I am not aware of any facility to be able to encrypt data in-place (I may be wrong) and from my knowledge, it's usually the case that the data is to be read through an encryption facility, apply an encryption key and then write out the encrypted data. Therefore, I can't see how you could conceivably encrypt existing data in-place. If using a software encryption tool, there is usually a high price to pay in terms of CPU cycles to undertake the encryption process and to try and encrypt an entire volume could prove fairly costly, time-wise at the completion of a DR exercise. Compare the time to encrypt in the manner you are suggesting to a software product that is quoted as being able to erase 3 Terrabytes of data in less than 2 hours. By the way, the folks on this list would probably appreciate it if you could sign your posts. Stephen Mednick Marketing Support Manager Computer Supervisory Services Tel: +61 (2) 9665 1104 Fax: +61 (2) 9665 7382 -- 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: Data Erasure Products
There are several data protection standards applying over here in Europe, but I would guess that I could at least defend myself to SOX auditors if I chose to use encryption in the scenarios I described. Alas, your mileage may vary in all of these things. My interest in the subject is at the theoretical one, which would hold that an adequate standard of encryption should allow you to leave data wherever it lies and not to worry about it so long as the finder doesn't have the key. Thanks for the replies! Niall -- 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
Young mainframers' group gains momentum
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. Young mainframers' group gains momentum http://www.networkworld.com/news/2008/013108-young-mainframers-group-gains.html Young mainframers' group gains momentum http://www.computerworld.com/action/article.do?command=viewArticleBasicarticleId=9060499 from above: ZNextGen, an organization aimed at young mainframe programmers, has gained significant momentum since it was created roughly two years ago through IBM and its user group, Share, according to its leaders. ... snip ... SHARE zNextGen http://www.znextgen.org/ from above: zNextGen, a user-driven community for new and emerging System z professionals that has the resources to help expediate your professional development skills. ... snip ... -- 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: Metal C
Tony Harminc wrote: Then it seems that METAL inhibits use of the ARCH option, so METAL C must generate code at the ARCH(CURRENT) level, which means it can (and does) use LARL and the like from the long displacement facility. Well, no, actually it accepts ARCH(5), which says is the default and generates code at the z900/z800 level, but it still generates LARL, which I don't believe is architected at that level. LARL was added to the ESA/390 instruction set implemented on the very first machines supporting z/Architecture. -- 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: Migration from Mainframe to othre platforms - the othe bell?
Opps, posted to the news group by accident. I will try and find the link, or you may find it when you do the Google, but there has been an update. The original migration to the mainframe was using IFL's on their existing IBM mainframes. After 1 year they had something like 700 virtual images, 200+/- production and the rest TEST and QA systems. They figured that they were going to save so much money from NOT having to upgrade their two data centers, reducing their environmental costs, reducing their software licensing fees, and reducing networking equipment costs, that they purchased 2 z9's just for the purpose of running Linux on zSeries. I can't remember exactly how many images they had on the z9's, but I think it was over 1,000. Kelman, Tom wrote: Are you interested in just z/OS stories or in stories about mainframe Linux also? One big story back in 2006 was the one about Nationwide Insurance moving the processing from 400 servers to 2 IBM z900 Linux systems. At the time they estimate the savings to by $15 million over 3 years. Here is one article on it or you can Google nationwide linux to get some more. http://www.linux.com/feature/59984 Tom Kelman Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mautalen Juan Guillermo Sent: Thursday, January 31, 2008 7:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Migration from Mainframe to othre platforms - the othe bell? -- 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: Data Erasure Products
On Jan 31, 2008, at 2:29 PM, George Fogg wrote: I have worked at several top secret installations in the past and I was told that they take the old DASD and drop them in a acid bath then cut them up. Never saw it happened so not totally sure it was done or not. George Fogg George, Well it would put an end to any thought of recovery that is for sure. Of course there was a TV episode about an acid bath and they did figure out the persons identity after it but that is TV for you. I wish I had a chance to ask an (now) ex-IBMer about this as it is an interesting issue. I am sure that security means different things to different people/companies. I would think the government has some sort of guidelines in this area as to how erase the data. What gets interesting on the new type of DASD is that the platters are not used for permanent DASD to me it is like a virtual dasd volume (much like the 3850). The security erasure would be a lot different in those types of equipment as data is never actually deleted just pointers are evaporated. I would hope the manufacturer would have a really good erase program (procedure). 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
Re: Data Erasure Products
On Jan 31, 2008, at 3:31 PM, Stephen Mednick wrote: --SNIP The downside of physically destroying the media as against using a certified erase solution to remove the contents is that the obsolete storage media can never be acquired on a lease-basis given that the box is not going to be able to be returned intact when the lease would have expired. For storage subsystems that have been purchased, there's no way that any residual value that the box might contain can be realised. Using a secure storage santisation or overwriting methodology, once the data has been removed, it's then possible to put out requests to second hand equipment dealers to submit an offer to acquire the box and remove it and at least get some dollars back. Stephan: It comes down purely (IMO) how valuable the data is. If its nuclear bomb data (or the like) then I would suggest that cost is not an issue. If its secure type data (ie HIPAA(sp?) or payroll or bank files) it is different . Each one probably has its own requirements. I am not a lawyer (and don't profess to be one). I would suggest that if there is any question get a lawyer to sign off on it or/in addition to the government agency that has jurisdiction in the area. 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
Re: Data Erasure Products
On Jan 31, 2008, at 5:15 PM, SUBSCRIBE IBM-MAIN Niall wrote: ---SNIP--- Unless there is some weird legislative standard which says that encryption is fine for transmission of data over open IP networks, but is not fine for resundant data held on permanent storage. OK.. but what encryption? and how many bytes of key are mandatory? 1 byte, 64 bytes or ? I do not pretend to know the answer, but for me if its really secure it doesn't go over an IP network I don't care how many bytes are in the encryption key. The IP (INTERNET) network was never meant to be a secure way of transferring data. *MAYBE* if its a private one and there are appropriate safe guards but *NOT* the Internet. I heard of a place in Switzerland that used a new kind of encryption that is anybody even copied(looked) at the data the the receiver was notified and the data was effectively vaporized. I believe the Swiss believe in security and when they go to this extreme just to transmit vote type data you can believe its secure. 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
Re: Managing system logger data
Skip, We're still at 1.7, so I can't speak to SMF data yet. Operlog we just set up with a 5 day RETPD in the logstream def'n. After that, Logger manages the datasets and makes them disappear. Copying to DASD for archiving is still done from the Syslog, and happens the way it always has. Syslog and Operlog are independant. For Logrec, IFCEREP1 has a LASTRUN parm. This marks the logstream data at the place that it last read up to, so that next time it's run it knows to start from there. Richard Crook zOS Technical Specialist, IBM Global Technology Services (64 4) 576-9795 [EMAIL PROTECTED] Skip Robinson Jo.Skip.Robinson @SCE.COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Managing system logger data 01/02/2008 01:58 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU After a decade of parallel sysplexing, I feel like a rookie with log streams. Up to now we've used system logger only for CICS and RRS. No operlog, no logrec. So we've never had to deal with the question of how to handle real data that needs to be kept (archived), massaged, and cleaned up. I'm now playing with the new SMF log stream available in z/OS 1.9. Not many folks have done this yet, but I think the problems are similar to other data-type log streams. Capturing the SMF data in a CF structure is easy. Logger writes the data out to data sets of the form 'hlq.IFASMF.xxx' where you choose the qualifier and tell the system what the name is. There is a new dump utility called IFASMFDL. Here's the problem. IFASMFDL does most of what IFASMFDP does (and more), but what it *doesn't* do is clear out the dumped SMF data. In other words, after archiving the contents of a log stream to a flat file, the now dumped records are still sitting just where they were. A subsequent run of IFASMFDL appears to pick up the same records all over again. The output file just gets bigger and bigger each time the dump is run. For those of you who use system logger for operlog or logrec, how do you clean up log streams so that you get one and only copy of all the data produced? . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The contents of this e-mail are confidential. If you have received this communication by mistake, please advise the sender immediately and delete the message and any attachments. Nothing in this email designates an information system for the purposes of Section 11(a) of the New Zealand Electronic Transactions Act 2002. Westpac New Zealand Limited. -- 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
Managing system logger data
After a decade of parallel sysplexing, I feel like a rookie with log streams. Up to now we've used system logger only for CICS and RRS. No operlog, no logrec. So we've never had to deal with the question of how to handle real data that needs to be kept (archived), massaged, and cleaned up. I'm now playing with the new SMF log stream available in z/OS 1.9. Not many folks have done this yet, but I think the problems are similar to other data-type log streams. Capturing the SMF data in a CF structure is easy. Logger writes the data out to data sets of the form 'hlq.IFASMF.xxx' where you choose the qualifier and tell the system what the name is. There is a new dump utility called IFASMFDL. Here's the problem. IFASMFDL does most of what IFASMFDP does (and more), but what it *doesn't* do is clear out the dumped SMF data. In other words, after archiving the contents of a log stream to a flat file, the now dumped records are still sitting just where they were. A subsequent run of IFASMFDL appears to pick up the same records all over again. The output file just gets bigger and bigger each time the dump is run. For those of you who use system logger for operlog or logrec, how do you clean up log streams so that you get one and only copy of all the data produced? . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Data Erasure Products
Stephan: It comes down purely (IMO) how valuable the data is. If its nuclear bomb data (or the like) then I would suggest that cost is not an issue. Ed, it's not a case of how valuable the data is, more importantly it's to do with what the security classification is that has been assigned to the data. Depending on the data's security classification dictates the media overwriting/sanitisation method that is it be deployed in accordance with government requirements. You'll find that these days most organisations are required to have a designated IT Security Advisor whose job it is to keep abreast of compliance regulations and requirements and ensure that they are being applied across the organisation and that corporate governance is being properly maintained. For heaven's sake, lets not bring the lawyers into this!!! I think this thread is developing the symptoms of drifting OT so let's try and hold it here. Stephen Mednick Computer Supervisory Services Sydney, Australia -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Data Erasure Products
[EMAIL PROTECTED] (Stephen Mednick) writes: it's not a case of how valuable the data is, more importantly it's to do with what the security classification is that has been assigned to the data. Depending on the data's security classification dictates the media overwriting/sanitisation method that is it be deployed in accordance with government requirements. security classification is simplification ... like role-based access qcontrol is simplification for permissions. ... recent post on dealing with permissions http://www.garlic.com/~lynn/2008b.html#26 folklore indeed the issue normally reduces to what is the threat model? security classification tends to be associated with threat model where divulging the information is not desirable ... and classification level attempts to make the measures to prevent information divulging proportional to the damange that might happen if the information is divulged (and/or the effort that an attacker will go to in order to get the data). For magnetic media this might be something like overwritting a specific number of times with (different) random data ... nist standard: http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf An example of how this gets simplified is example of consumer financial information stored at a merchant. The damage gets translated into security proportional to risk ... and the risk is what is the value of the information to the merchant ... old post on the subject: http://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk The problem is that the real threat model and therefor risk, is that the value of the information to the consumer (and to any attacking crook) is possibly one hundred times larger than the value of the information to the merchant. The merchant is required to keep transaction logs (and the associated account numbers) for some period as part of mandated business processes. The information value (to the merchant) is some part of the merchant's profit margin on the transaction ... for hypothetical example for some number of product transactions, this could be $10,000. The value of the information to the crook, is related to the credit limits associated with the individual accounts. This could conceivable be $10,000,000 (totally unrelated to the value of the information to the merchant, i.e. some portion of the profit on the purchased products). Since the value to the crook can be 100 to 1000 times larger, the attacking crooks can afford to outspend the defending merchants by possibly one hundred times. in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. Part of this was looking in detail at end-to-end vulnerabilities and threat models ... as part of coming up with x9.59 financial standard http://www.garlic.com/~lynn/x959.html#x959 part of the x9.59 financial standard was eliminating the usefulness of the account transaction log information (at merchants) to attacking crooks i.e. it didn't involve trying to prevent attacking crooks from getting at the information ... it just made the information useless to crooks for performing fraudulent financial transactions. A different example was we also got involved in co-authoring the financial industry x9.99 privacy standard. As part of that we had to look at both GLBA and HIPAA (financial transactions can used for medical procedures which may be listed). One of the issues in HIPAA is that there is a real requirement to make some amount of medical procedure information available. At a result, HIPAA allows for information to be available if it can't be associated with an individual (aka deidentified). deidentified Under the HIPAA Privacy Rule, data are deidentified if either (1) an experienced expert determines that the risk that certain information could be used to identify an individual is 'very small' and documents and justifies the determination, or (2) the data do not include any of the following eighteen identifiers ... snip ... As part of working on x9.99, we put together a privacy merged taxonomy and glossary ... see: http://www.garlic.com/~lynn/privacy.htm for other details see notes at http://www.garlic.com/~lynn/index.html#glosnote -- 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: OT 1TB Drive and 37 hours
I have two of them and neither took over 3 hours to format. I noticed that they had accepted the auto update of Vista, which was pretty dumb of them in the first place, and that appears to be what caused their problem. I replaced 2 WD 500GB drives with these, and while I thought they were very quiet, I am very pleased at the fact that it's now just about silent. They also appear to run about 10 degrees F cooler. 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: identify sas usage by component
On Jan 31, 2008, at 11:02 AM, Gary Green wrote: I have not followed this thread so forgive if this was covered earlier... Speaking off the top of my head (yeah, I know, I know...) I need to leave aside the fact that any change to an OEM's SMF record requires tweaking of any vendor record specific downstream processing. If all this processing is done in-house, that's no big deal. A slight tweak to Barry's MXG record definitions, could handle that. If the data is sent to the vendor, that is easy as well. Just coble something together to reverse the changes. ... How about looking into writing an SMF Dump Program exit where you would modify the OEM SMF records on the fly and use your own record-type/ sub-type numbering scheme. As the records pass through your exit, you would modify the appropriate records before they are written to the SMF dump tape/disk file. 1. If the vendor's SMF record uses a header with the SMFxSTY (subtype) field, dump a few thousand of their records to see if they actually use the STY field or is the value constant. If constant, it's possibly ripe for you to use. For this type of record, change the record type and subtype to your liking. XX for the record type and yy for sub-type for vendor yy, and zz for vendor zz and so on. 2. If the vendor's SMF record does not use a header with the SMFxSTY (subtype) field (most likely), you have two options. A. You could reformat the record header to make it support subtypes. Allocate a buffer to rebuild the record, copy the existing original 18 byte header and actual Vendor SMF record data to the appropriate area in the buffer and change the record type then insert the subtype in the SSY field to represent that specific vendor. Of course, if the vendor's record uses triplet fields, they would need to be modified as well. I would review the documentation from the vendor for this information. As for the SSI field, I would ignore it since it was never there in the first place. B. You could use the SMFxFLG field. I look at records all the time and I do not recall ever seeing a vendor actually using this field; of course YMMV. That said, I dumped a million SMF records between 128-255 they all contain the same value; 1E in my case. You could use this field for your vendor specific sub-type value and then change the record type. Of course, this will only provide you a 16:1 reduction in used records types but that's better than nothing. ;) .. Now, if one were to entertain this idea, the big question is, if multiple vendors use the same SMF record type, how does one distinguish one vendor's record from the others that are using the same record type. Generally, there is almost always some type of eye-catcher in the record that would give it away. A simple branch table/array to identify the records to process. In that table/array you could have an offset to the eye-catcher location to interrogate and another pointer to an array of values to compare against, any one of which would be a hit. JMTC... Sure that is possible if you *OWN* the programs in question but our issue at the time was OEM code (usually in COBOL) and you can't change the code. If you do you own it. Then there is the issue of maintaining the code with (about) 3 updates a year. Our staff was not equipped to handle that type of change. Yes we were understaffed but who isn't? At the time we had one individual handling the SMF products and he really worked his butt off doing so. Add to that we were on the bleeding edge of IBM PTF's it was all we could handle plus the installation of OEM software plus we had quite a few experimental (more like early ship) equipment (DASD TAPE) and few other items like we were FCS on some IBM controllers that we were dying to get our hands on as we were busting our seams trying to keep the number of UCB's below the magic number and and and... in other words we had our hands full. I am sure there are ways but since we didn't own the code and the vendors were not sympathetic about us touching their code. I won't go into the vendor arm twisting that was done and it was tried just a dead end. One vendor told us that they would charge us 25K a hear and an hourly rate if we really needed it. Even if we could have gotten the same deal (unlikely) from the other 3 that would have raised the cost to probably over 100K a year. 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
Re: Job ad for z/OS systems programmer trainee
On Jan 31, 2008, at 2:13 PM, Gary Green wrote: Well, all us write in our resumes that we look for a challenge. From that position profile, I can't think of anything more challenging. :) Would you really take that type of a job... out in the middle of a desert and LA is a good 90 miles away. Yes there is a community (albeit all government type people) Secrecy is all around you and probably your next door neighbor is spying on you. Its like living in the back hills of the south. You certainly would not be allowed to join in on here you would miss the toothless biting humor of Ron H and the 1 (or 2) word answers from Schmuel all you would be able to do is stare out on the desert at night. And the high point would be if someone runs a red light. 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
Re: Managing system logger data
On Jan 31, 2008, at 6:58 PM, Skip Robinson wrote: ---SNIP--- Here's the problem. IFASMFDL does most of what IFASMFDP does (and more), but what it *doesn't* do is clear out the dumped SMF data. In other words, after archiving the contents of a log stream to a flat file, the now dumped records are still sitting just where they were. A subsequent run of IFASMFDL appears to pick up the same records all over again. The output file just gets bigger and bigger each time the dump is run. For those of you who use system logger for operlog or logrec, how do you clean up log streams so that you get one and only copy of all the data produced? . Skip: Not sure this is a solution but it might be worth a try. Sort the SMF records each time and specify in sort to drop duplicate records. That was you should get only 1 record and the other 1 will be dropped. 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
