Re: PIPELINES and Deblocking(Cross posted in CMSPIPELINES Listserve)
On Wed, 9 Jul 2008 12:52:54 -0400, Hughes, Jim <[EMAIL PROTECTED]> wr ote: >Adam is pretty sensitive isn't he? > >I wish someone would create a WHOPPER to compete with a MAC. > >There is hope for the MAC users yet. The hackers have decided there are >enough MAC's around to start creating viruses targeting them. Not really. Still no viruses (viri?). What there have been recently is Tr ojan Horses. Mostly based on errors in programs that run everywhere, not in Mac OS or Mac-specific pro grams. There isn't much you can do about someone downloading a program and then executing it! At least the Mac now tells you -- "You are running this program for the f irst time, are you sure you want to execute it?" Or sometimes "You just downloaded this from the Internet, are you sure yo u want to execute it?" I'm sure it won't last forever. But 24 years of never getting a single vi rus at home is pretty cool. (At work we had Code Red and all sorts of others.) Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: PIPELINES and Deblocking(Cross posted in CMSPIPELINES Listserve)
On Wed, 9 Jul 2008 10:25:53 -0400, [EMAIL PROTECTED] <[EMAIL PROTECTED] ftware.com> wrote: >Jim, > >it looks like you have a Mac user to deal witharen't they a pain? :- ) > >Windows record termination: x'0d0a' >Unix record termination: x'0a' >Mac record termination: x'0d' > And, of course, mainframes use"out of band" record termination. It's more complicated than that. Mac OS X is built on BSD Unix. Record te rminator is LF. But many existing Mac programs still use CR. Occasionally you will have the Unix F TP transferring an old Mac OS file. This causes problems! The Internet has a standard record separator of CRLF. In theory, that sho uld avoid all these incompatibilities. However, if you use Binary FTP transfer, then all bets are off. And some Unix programs use LF instead of CRLF, on the assumption that everything in the Internet is Unix. It sure would have been nice if the ASCII "Standard" had specified what t o do with the darn control characters. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
SHARE: Last call for session chairs
SHARE in San Jose is getting very close. There are still plenty of sessions that are in need of chairs. We can really use your help to step up to volunteer. Your job is to meet the speaker (if you haven't already), introduce the speaker to the audience, keep discussions on topic, count attendees, keep time for the speaker (because frankly some of them are time challenged) and most important to the welfare of the program: collect the prized session evaluation slips and return them to headquarters (or a designated drop off location near you). Your reward as a session chair will be the satisfaction of helping out at SHARE and the admiration of your fellow attendees. Following is the list of the remaining unchaired sessions for the Linux and VM program by day and time (please watch the wrap). Feel free to respond to me with the session number that you wish to chair. Responses will be accepted on a first come, first chaired basis. NumberDayTimeTitleSpeaker 9102Mon09:30aThe Very Basics of z/VM - Concepts and TerminologyBill Bitner 9268Mon09:30aOpenKicks: The CICS API on LinuxMichael Potter 9113Mon01:30pThe z/VM Control Program (CP) - Useful Things to Know John Franciscovich 9200Mon01:30pAn Introduction to Linux and Open Source Jim Elliott 9127Mon03:00pz/VM for MVS Systems Programmers - Part 1 of 2 Martha McConaghy/Mark Post 9128Mon04:30pz/VM for MVS Systems Programmers - Part 2 of 2 Martha McConaghy/Mark Post 9234Mon04:30pManaging Linux under z/VM using the Linux Performance Suite (ESALPS)Barton Robinson 9265Tue08:00aTCO: Comparing System z and Distributed Environments; Building the Business CaseMarlin Maddy 9233Tue09:30aLinux Installation PlanningMark Post 9261Tue11:00a(Dis)Honest TCO Analysis for Linux on System z Romney White/Erich Amrehn 9284Tue11:00aHow To Turn a Penguin Into a Dog (or, Things To Do That Will Avoid Linux on z Success)Philip Smith 9133Tue01:30pConfiguring, Customizing and Modifying Your VM System Without an IPLJohn Franciscovich 9227Tue01:30pLinux for IBM System z Installation Hands-on-Lab - Part 1 of 3Richard Lewis 9262Tue01:30pWhat's New in Linux on System z?Martin Schwidefsky 9119Tue03:00pz/VM Installation - From Cardboard Box to IPL Mike Walter 9134Tue03:00pDynamically Managing Hardware I/O Configuration Using VMRick Barlow 9228Tue03:00pLinux for IBM System z Installation Hands-on-Lab - Part 2 of 3Richard Lewis 9238Tue03:00pConfiguring Linux on z/VM for Performance Barton Robinson 9229Tue04:30pLinux for IBM System z Installation Hands-on-Lab - Part 3 of 3Richard Lewis 9240Tue04:30pLinux on z/VM System Programmer Survival Guide Robert (Jay) Brenneman 9152Wed08:00aOMEGAMON XE on z/VM and Linux - What's New and How Do I Install What I Have?Robert Neill 9235Wed08:00aAnalyzing and Tuning Linux Storage in z/VM environment Barton Robinson 9242Wed08:00aLinux for Beginners Hands-on-Lab - Part 1 of 3 Neale Ferguson 9202Wed09:30aLinux on System z - A Strategic ViewJim Elliott 9243Wed09:30aLinux for Beginners Hands-on-Lab - Part 2 of 3 Neale Ferguson 9248Wed09:30aHelp! My (Virtual) Penguin is Sick!Philip Smith 9244Wed11:00aLinux for Beginners Hands-on-Lab - Part 3 of 3 Neale Ferguson 9230Wed01:30pSaving Real Storage with Execute in Place on Linux for System zIhno Krumreich 9146Wed03:00pUsing Unicenter VM:Operator To Manage Linux Servers Brian Jagos 9156Wed03:00pConfiguring LDAP on z/VM and LinuxRich Smrcina 9129Wed04:30pz/VM Security and IntegrityAlan Altmark 9259Wed04:30pSCSI over FCP for Linux on System z - Introduction and New FeaturesChristof Schmitt 9158Wed06:00pServer Virtualization Technical and Total Cost Analysis Montgomery Bauman 9237Wed06:00pLinux under z/VM Performance Analysis Case Studies Barton Robinson 9297Wed06:00pLinux on System z Information - Help us to help you! Maria Eisenhaendler 9117Thu08:00aIntroduction to Installation and Service of z/VM using VMSES/EJim Vincent 9224Thu08:00aLinux System Management for the Mainframe System Programmer - Part 1 of 2Mark Post 9250Thu08:00aBasic Linux Scripting Hands-on Lab - Part 1 of 2Neale Ferguson 9280Thu08:00aLinux on System z - What's new in the I/O Area Horst Hummel 9118Thu09:30aServicing and Maintaining z/VM with VM/SES - Live Demo Jim Vincent 9225Thu09:30aLinux System Management for the Mainframe System Programmer - Part 2 of 2Mark Post 9251Thu09:30a
Re: Hipersocket Capacity
> > Reminds me of the customer who measured the OSA bandwidth by copying > the ISO image from one Linux machine to the other with "scp" (burning > his shared IFL by encrypting and decrypting the file). > That's how one Linux (on Intel) expert "proved" to management that "hipersockets are slower than the regular network", and thereby killed off zLinux at his shop. MW
Re: Hipersocket Capacity
On Wed, Jul 23, 2008 at 10:10 PM, Steve Mitchell <[EMAIL PROTECTED]> wrote: > Measure it. It is a function of CPU. > > Where might I find some guidance on how to accomplish that? In Therory "I > understand what you are expressing" In Practice "I dont have much of a > clue about how to go about it". The ESACHNH screen in ESAMON shows the hipersockets counters. Every unit of data takes one cycle, and there's a model dependent number of cycles per second. So you can compute a utilization (except that we have an issue with the hardware not showing all the counters). But I have not yet seen data where that was an issue. The cost of the virtual machine processing the data sent over hipersockets is normally the limiting factor. Reminds me of the customer who measured the OSA bandwidth by copying the ISO image from one Linux machine to the other with "scp" (burning his shared IFL by encrypting and decrypting the file). -- Rob van der Heij Velocity Software http://velocitysoftware.com/
Re: Size of SFS control backup
This does beg the question, is there any significant performance difference when writing to the filemode vs. writing to an unaccessed directory? Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij > Sent: Wednesday, July 23, 2008 3:12 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Size of SFS control backup > > On Wed, Jul 23, 2008 at 8:31 PM, Alan Altmark > <[EMAIL PROTECTED]> wrote: > > > Use an ENDCMD nucleus extension to check for and re-access > any missing > > directories. > > You mean in the SFS server to catch it when it falls in CMS > Ready ? Yuck. > > And it's way more useful than just there. When we ran CMS > applications in a larger CS configuration, taking one system > out would make CP find the other route immediately. But any > directories accessed in applications were released due to > this. I know we could change the applications to write to SFS > files directly rather than via a filemode, but that's serious > changes. Would be nice if CMS would just retry the ACCESS > when you need it, instead of forcing the RELEASE. > -Rob >
Re: Size of SFS control backup
On Wed, Jul 23, 2008 at 8:31 PM, Alan Altmark <[EMAIL PROTECTED]> wrote: > Use an ENDCMD nucleus extension to check for and re-access any missing > directories. You mean in the SFS server to catch it when it falls in CMS Ready ? Yuck. And it's way more useful than just there. When we ran CMS applications in a larger CS configuration, taking one system out would make CP find the other route immediately. But any directories accessed in applications were released due to this. I know we could change the applications to write to SFS files directly rather than via a filemode, but that's serious changes. Would be nice if CMS would just retry the ACCESS when you need it, instead of forcing the RELEASE. -Rob
Re: Size of SFS control backup
On Wed, Jul 23, 2008 at 8:25 PM, Sue Farrell <[EMAIL PROTECTED]> wrote: > You can direct the control data backup to another file pool using the > explicit directory name and thus, avoid the access, and the problem of the > access going away. > Eg. fileserv defbackup disk backup data fpname:username.dir > Backing up to tape is another method (besides minidisk). Cool! I had not noticed that. I would still be stuck if the filepool is down when it wants an unplanned backup, but this helps reduce the risk. Tape would be even worse in this aspect. Rob
Re: Use of surfstats etc on IBM web sites
Hello! Rob, it happens that you are not the only one who is annoyed by those dratted things. They make the site unavailable during loading when it's being loaded by IE, and it drags on Mozilla, both on Linux and Windows. About the only good thing about the site is its good lucks, it has an easy to use navigation method behind it. I believe I've got the settings arranged to block that function on both browsers -- Gregg C Levine [EMAIL PROTECTED] "The Force will be with you always." Obi-Wan Kenobi > -Original Message- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Rob van der Heij > Sent: Wednesday, July 23, 2008 1:39 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: OT: Use of surfstats etc on IBM web sites > > Am I the only one being annoyed by the way IBM implemented their > visitor statistics? There seem to be (javascript) things connecting to > sites with surfstats and such. At least on my browser (Mozilla) they > have a negative effect that it prevents navigation on the page until > it has fully loaded. My impression is that these statistics sites may > not build on the framework of replica servers that IBM uses for the > real content, and thus has higher latency for me. > I know I can put them in adblock again (lost that with windows > re-install) but it seems like a silly cat & mouse game to me. > > I did share my concerns with one contact in IBM, but he said he could > not care less because anything above the dotted line was not his > responsibility... > > Rob
Re: Interpreting Trace
On Wednesday, 07/23/2008 at 04:22 EDT, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > Thanks to your excellent interpretation of the trace, the vendor has > re-examined their microcode and found where they were indeed causing the > UC. They are working on a fix. (And they once told me that the TRSOURCE > and console were not useful in solving this problem. Out of nothing > comes something.) It's kinda sad if THEY couldn't interpret the trace. They're in the I/O business and this should be obvious to them! Glad to have helped. Alan Altmark z/VM Development IBM Endicott
Re: Hipersocket Capacity
On Wednesday, 07/23/2008 at 04:15 EDT, "McKown, John" <[EMAIL PROTECTED]> wrote: > Just some thoughts on this. From what I understand, a hipersocket is > really a way to "move" data from one memory location in one LPAR to > another memory location on another LPAR in the same CEC. Or to the same LPAR, it doesn't matter. > Now, is that > "move" done by a CP? Or is it done by the SAP? If it is done by a CP, > then it is "knee-capped" if the CP is "knee-capped". If it is done by a > SAP, then it is not. I would hope that it is actually done by a SAP. But > that would mean that the speed could be influenced by how busy the SAP > is doing other things. Given that CP's are millicoded, I think you cannot presume that internal speed and apparent speed are the same. HiperSockets is internal to the CPU, using iQDIO interfaces, and is synchronous with respect to data movement. That is, the data is not stored "somewhere else". So, only if they actually turn down the clock speed would it necessarily be slower. Hence, measure it and find out if *your* workload on *your* system would benefit. Alan Altmark z/VM Development IBM Endicott
Re: SUSE Linux Enterprise Server 10 SP2 Starter System for IBM System z
We are running 8.2 in 64-bit with SP3. However, I plan on installing SLES 10 SP2 under z/VM 5.3 as a new install. Thanks, Alyce -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Tuesday, July 22, 2008 3:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SUSE Linux Enterprise Server 10 SP2 Starter System for IBM System z >>> On Tue, Jul 22, 2008 at 6:03 PM, in message <[EMAIL PROTECTED]>, "Austin, Alyce (CIV)" <[EMAIL PROTECTED]> wrote: > I'm glad to hear that you were successful. We will be upgrading > from SuSE 8.2 to SuSE 10 sp2. Not all in one jump, I hope, as that isn't a supported upgrade path. Even if you do it in multiple steps, you also need to know that going from 31-bit to 64-bit is not a supported (or workable) upgrade path. Mark Post
Re: Interpreting Trace
Thanks to your excellent interpretation of the trace, the vendor has re-examined their microcode and found where they were indeed causing the UC. They are working on a fix. (And they once told me that the TRSOURCE and console were not useful in solving this problem. Out of nothing comes something.) Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Wednesday, July 23, 2008 9:52 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Interpreting Trace > > On Wednesday, 07/23/2008 at 11:47 EDT, Rob van der Heij > <[EMAIL PROTECTED]> wrote: > > > But Sir Mike! The modern 3480 cartridge does not do shiny bits > > anymore. After all, the cartridge is closed so there is no > light that > > will go in to shine ;-) The control unit is smart enough > to count the > > operations that move the tape, and indeed... virtualizes BOT. > > The drive doesn't have to count operations. The drive knows > where BOT and EOT are at all times because of block numbers > and other information encoded on the servo track. (The > presence of the servo track is why you must not degauss a > cartridge tape.) > > Alan Altmark > z/VM Development > IBM Endicott >
Re: Hipersocket Capacity
> -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Wednesday, July 23, 2008 3:07 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Hipersocket Capacity > > On Wednesday, 07/23/2008 at 02:59 EDT, Steve Mitchell > <[EMAIL PROTECTED]> wrote: > > How does one go about determining the 'capacity' of a Hipersocket > > connection/interface between z/OS- z/VM? > > Measure it. It is a function of CPU. > > I don't know if sub-cap machines run HiperSockets at full > speed or not. I > doubt it. > > Alan Altmark Just some thoughts on this. From what I understand, a hipersocket is really a way to "move" data from one memory location in one LPAR to another memory location on another LPAR in the same CEC. Now, is that "move" done by a CP? Or is it done by the SAP? If it is done by a CP, then it is "knee-capped" if the CP is "knee-capped". If it is done by a SAP, then it is not. I would hope that it is actually done by a SAP. But that would mean that the speed could be influenced by how busy the SAP is doing other things. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Hipersocket Capacity
Measure it. It is a function of CPU. Where might I find some guidance on how to accomplish that? In Therory "I understand what you are expressing" In Practice "I dont have much of a clue about how to go about it". Steve Mitchell Sr Systems Software Specialist Blue Cross Blue Shield of Kansas (785) 291-8885 'There are no degrees of Honesty-you're either Honest or you're not! CONFIDENTIALITY NOTICE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain proprietary, confidential, trade secret or privileged information. Any unauthorized review use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Re: Hipersocket Capacity
On Wednesday, 07/23/2008 at 02:59 EDT, Steve Mitchell <[EMAIL PROTECTED]> wrote: > How does one go about determining the 'capacity' of a Hipersocket > connection/interface between z/OS- z/VM? Measure it. It is a function of CPU. I don't know if sub-cap machines run HiperSockets at full speed or not. I doubt it. Alan Altmark z/VM Development IBM Endicott
Re: CSE and VMSERVx
I also find (aside from where Tom's suggestion is needed) that it is helpful for the VMID of the SFS server to match the name of the filepool it serves. -- R; <><
Hipersocket Capacity
How does one go about determining the 'capacity' of a Hipersocket connection/interface between z/OS- z/VM? Steve Mitchell Sr Systems Software Specialist Blue Cross Blue Shield of Kansas (785) 291-8885 'There are no degrees of Honesty-you're either Honest or you're not! CONFIDENTIALITY NOTICE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain proprietary, confidential, trade secret or privileged information. Any unauthorized review use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Re: Use of surfstats etc on IBM web sites
Is it 1987 again? I presume that this was not someone at the VM Support center. In case you were not around in 1987, it was the year that John Akers declared to be "the year of the customer"; however, he failed to communicate that to some of his employees. It wasn't until 1988 or 1989 that the answers of WAD (working as designed) and BAD (broken as designed) were eliminated from the vocabularies of the support staff. Those were the bad old days. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij > Sent: Wednesday, July 23, 2008 10:39 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: OT: Use of surfstats etc on IBM web sites > > > I did share my concerns with one contact in IBM, but he said > he could not care less because anything above the dotted line > was not his responsibility... > > Rob >
Re: Size of SFS control backup
On Tuesday, 07/22/2008 at 02:30 EDT, Rob van der Heij <[EMAIL PROTECTED]> wrote: > On Tue, Jul 22, 2008 at 8:28 AM, Rob van der Heij <[EMAIL PROTECTED]> wrote: > > > The description of this process does not look like it was for production use. > > Maybe we need SFS to be enhanced to access the filemode as specified > before trying to backup. Or my long-standing desire for CMS itself to > re-access the SFS directory when the connection was lost since last > time (because at that point CMS still knows what it was, and you don't > after the forced RELEASE). Use an ENDCMD nucleus extension to check for and re-access any missing directories. Alan Altmark z/VM Development IBM Endicott
Re: Size of SFS control backup
I'm a little late to this discussion, but there are a couple things I wanted to respond to: > Thanks! That explains why I filled it up and how big it should be. Did > I miss it, or is it really not in book? > -Rob There is a section titled "DASD Space Needed for Control Data Backup" in Chapter 7 of the CMS File Pool, Planning, & Administration book. > The problem with that is if you have to recycle that filepool with the > control backups, the access will be gone and the control backup fails. > And I believe that unless you poke in the SFS server, you can't > re-access that other than STOP NOBACKUP and restart? > -Rob You can direct the control data backup to another file pool using the explicit directory name and thus, avoid the access, and the problem of th e access going away. Eg. fileserv defbackup disk backup data fpname:username.dir Backing up to tape is another method (besides minidisk).
OT: Use of surfstats etc on IBM web sites
Am I the only one being annoyed by the way IBM implemented their visitor statistics? There seem to be (javascript) things connecting to sites with surfstats and such. At least on my browser (Mozilla) they have a negative effect that it prevents navigation on the page until it has fully loaded. My impression is that these statistics sites may not build on the framework of replica servers that IBM uses for the real content, and thus has higher latency for me. I know I can put them in adblock again (lost that with windows re-install) but it seems like a silly cat & mouse game to me. I did share my concerns with one contact in IBM, but he said he could not care less because anything above the dotted line was not his responsibility... Rob
Re: Moving SFS user
To be more explicit, the command is FILEPOOL UNLOAD. From a SFS administrator id, assuming "JOEUSER" is the file space you w ant to move, access the 193 disk and issue - FILEDEF UNLOAD DISK JOEUSER UNLOAD where is large enough to contain the file space - FILEPOOL UNLOAD FILESPACE JOEUSER VMSYSU And then on the 5.3 system: - FILEDEF RELOAD DISK JOEUSER UNLOAD - FILEPOOL RELOAD FILESPACE JOEUSER VMSYSU HELP SFSADMIN FILEPOOL for more notes. Sue
Re: Z/VOS - separate topic for MS Windows in CMS
Please see original thread: Nice idea in blog: Should we toss x86 architecture This was our post to the zd net blog. "Maybe we already have. In Q1 2009 Mantissa will deliver a system that permits unaltered Windows operating systems to run under z/VM. Using a desktop appliance running RD C, users will be able to connect to their virtual Windows images running in the VM environment. Goodbye desktop hardware, remote maintenance, high power consumption, machine order lead time. z/VOS began with the observation that most Windows workstations do practically nothing 95% of the time and we were so intrigued with the ide a of being able to actually run an intel-based operating system under IBM V M that we never looked back. VM provided a natural platform for development of this product. The product has been a bear for the development group but the thought of being able to run 3000 copies of Windows on one System z so fascinated th e team that we needed very little additional incentive. Let's hope IBM can ramp up System z production." Why wait until 2016? --. .- .-. -.-- Gary Dennis Mantissa Corporation
Re: Interpreting Trace
On Wednesday, 07/23/2008 at 11:47 EDT, Rob van der Heij <[EMAIL PROTECTED]> wrote: > But Sir Mike! The modern 3480 cartridge does not do shiny bits > anymore. After all, the cartridge is closed so there is no light that > will go in to shine ;-) The control unit is smart enough to count the > operations that move the tape, and indeed... virtualizes BOT. The drive doesn't have to count operations. The drive knows where BOT and EOT are at all times because of block numbers and other information encoded on the servo track. (The presence of the servo track is why you must not degauss a cartridge tape.) Alan Altmark z/VM Development IBM Endicott
Re: Interpreting Trace
I hope it means something to the vendor. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Wednesday, July 23, 2008 9:37 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Interpreting Trace > > On Wednesday, 07/23/2008 at 11:46 EDT, "Schuh, Richard" > <[EMAIL PROTECTED]> > wrote: > > Alan, When you said the error is being raised by path 2 to the > > device, > were > > you referring to a chpid? The response to a query paths > command shows > only > > one path. > > I think that's the local "adapter" number, as seen by the > control unit. Of course, since it's bogus SENSE data, it may > not mean anything at all. > > Alan Altmark > z/VM Development > IBM Endicott >
Re: Interpreting Trace
On Wednesday, 07/23/2008 at 11:46 EDT, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > Alan, When you said the error is being raised by path 2 to the device, were > you referring to a chpid? The response to a query paths command shows only > one path. I think that's the local "adapter" number, as seen by the control unit. Of course, since it's bogus SENSE data, it may not mean anything at all. Alan Altmark z/VM Development IBM Endicott
Re: Interpreting Trace
The earliest generation, the 3420-07, used the virtualized lights. I think it was really old vacuum tubes from the 30 minute rewind time. They had to warm up before there was enough light to be detected. ;-) The newest generation is said to be a 3490. However, its responses to SenseId and RDC make it appear to be a 3480-04. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, July 23, 2008 9:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Interpreting Trace But Sir Rob the Plumber, even the old 3420 drives had internal incandescent lights in the tape path to shine on the reflector. No need for external light to reflect on the strip! One might only presume that the hardware manufacturer of this pseudo virtualized tape drive has installed virtualized LEDs (using less virtualized electricity than old-fashioned virtualized incandescent bulbs, important in this "green" day and age) to shine on a virtualized reflector strip? ;-) But that of course begs the question of whether this virtualized tape drive might have problems with their virtualized vacuum columns (for which some manufacturers used light bulbs to detect tape location, too!)? Or... didn't Richard say way back at the beginning of the thread that this was a virtualized 3490? Never mind! :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Rob van der Heij" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 07/23/2008 10:47 AM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Interpreting Trace On Wed, Jul 23, 2008 at 5:33 PM, Mike Walter <[EMAIL PROTECTED]> wrote: > Say... could it be that the virtualized silver tape reflector fell off the > beginning or end of the virtualized tape? And are you sure that the > virtualized silver tape reflector is on opposite edges of the shiny surface > of the virtualized tape media? I can't remember which edge gets the leading > and trailing silver tape reflectors. You'll have to ask your hardware > supplier to experiment with opposite edges. ;-) But Sir Mike! The modern 3480 cartridge does not do shiny bits anymore. After all, the cartridge is closed so there is no light that will go in to shine ;-) The control unit is smart enough to count the operations that move the tape, and indeed... virtualizes BOT. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Interpreting Trace
I had considered it, but there are two problems: 1. Logoff (voluntarily or by FORCE) goes through the DETACH code without LEAVE 2. DETACH ... LEAVE requires Class B. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Mike Rydberg > Sent: Wednesday, July 23, 2008 8:28 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Interpreting Trace > > Richard, > > Perhaps the DETACH command with the LEAVE option might avoid > the REWIND/UNLOAD problem with this device. > > Mike Rydberg > Brocade > > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard > Sent: Wednesday, July 23, 2008 10:23 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Interpreting Trace > > Thank, Alan. Your analysis confirms my faded memories of the > channel and device protocols. I will pass the information on. > > Actually, there is no BOT and there is no tape. The vendor > chose to reply like a tape drive to the roll-call for reasons > unknown to me. I speculate that it is because tape units can > be written to and read from in a successive operations. If > that is the case, they could have chosen an old printer that > allows one to read the print buffer. And they respond > unconditionally to sense commands as though the device were at BOT. > > Regards, > Richard Schuh > > > > > -Original Message- > > From: The IBM z/VM Operating System > > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > > Sent: Tuesday, July 22, 2008 6:11 PM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: Re: Interpreting Trace > > > > On Tuesday, 07/22/2008 at 01:57 EDT, "Schuh, Richard" > > <[EMAIL PROTECTED]> > > wrote: > > > TRACE TYPE IO, CPU 0005 TIME 16:28:05.323115 > > >TRACEID = T670, TRACESET = NULL, IODATA = 128 > > >USER = SYSTEM, I/O OLD PSW = 0704D001 8000 > > 002C0FBE > > >DEVICE = 0670, SCSW = 01C04017 00AA4088 0E01 ** > > I/O ERROR > > > ** > > > > >ESW = 0080 > > >I/O PRIORITIES: CHANNEL = 0, CURRENT = 255, > ORIGINAL = 255 > > > OUT-PRIORITIZED COUNT = 0 > > > -> CCW(1) = 0761 , CCW ADDRESS = 00AA4080 > > >** INVALID DATA ADDRESS ** > > > -> CCW(2) = 0F21 , CCW ADDRESS = 00AA4088 > > >** INVALID DATA ADDRESS ** > > > > > The vendor says that the device has been modified to return > > Device End > > for both > > > the Rewind (CCW Op Code 07) and the Rewind and Unload (0F) > > commands. > > > In > > the > > > penultimate entry, you can see that there is a Rewind chained to a > > Rewind and > > > Unload. Both of those CCWs are flagged in the trace as > > having invalid > > data > > > addresses. This is puzzling because the I/O was generated > by CP. If > > there are, > > > indeed, invalid data addresses, sould that not cause a > > Channel Program > > Check or > > > some other error rather than Command Reject? Why is CP > using invalid > > channel > > > programs in the first place? > > > > Those are control operations. The address and length > fields are not > > [supposed to be] used by the device. The channel does not generate > > UNIT CHECKs and does not manufacture SENSE data. The 'invalid data > > address' is the result of a determination by CP, not the channel > > subsystem, at the time the record was cut. I've seen this when CP > > puts bad addresses in CCWs specifically to catch unexpected data > > transfer attempts. > > > > > Here is the pertinent section from the OPERATOR console: > > > > > > 15:47:21 TAPE 0670 DETACHED RSCHUH 0670 BY > > RSCHUH > > > 15:47:21 HCPERP500I TAPE 0670 AN OPERATION WAS > TERMINATED BECAUSE > > A > > > 15:47:21 HCPERP500I COMMAND REJECT ERROR > > OCCURRED > > > 15:47:21 HCPERP6300I SENSE DATA FORMAT = 02 MSG CODE = > > 00 > > > 15:47:21 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = > > 07 > > > 15:47:21 HCPERP6303I SENSE = 80482427 0020 > > > > > 15:47:21 HCPERP6303I 0F01 > > > > > 15:47:21 HCPERP6304I IRB = 01C04017 00AA4088 0E01 > > 0080 > > > 15:47:21 HCPERP6305I USERID = > > SYSTEM > > > 15:47:21 HCPERP2216I CHANNEL PATH ID = > > 52 > > > 15:47:21 HCPERP2220I PHYSICAL CHANNEL PATH ID = > > 0168 > > > > > > According to the vendor, their internal trace shows that > > their machine > > received > > > the Rewind and responded with Device End. The next thing > > they saw was > > the Sense. > > > > The first 4 bytes of SENSE data (80482427) show that > > - X'80': The device is rejecting the REWIND > > - X'48': Drive is online and is at b
Re: Interpreting Trace
It is not a tape at all. Neither is it a disk. It is an encryption device that responds to sense commands like it is a tape unit. A bit of history of the device * Generation 1 was parallel channel connected. It required an RDEVICE statement saying that it was a 3420 model 7. When one was detached from a user, it took nearly 30 minutes to rewind. However, there were no I/O error messages associated with its detachment. * Generation 2 is ESCON connected. It responds to roll-call as if it is a 3480-04. It does not require an RDEVICE. It does return unsolicited sense data when detached from a guest, but there is nothing that appears actionable to the operators in the messages that are generated. * Generation 3 is also ESCON. Initially, it streamed unsolicited interrupts when detached. That has been corrected. Now it gives the command rejects. Since this is a VM-only problem, TPF knows not to rewind it, we could live with the errors at detach time. There would be anywhere from a handful to a few dozen per day. That said, I would rather not condition our operators to become inured to the "normal operation" I/O error messages. They might dismiss real errors as being normal. Why not just code the devices as unsupported devices with DEVCLASS TAPE? It seems that we are taking a step backwards if we do that. The Generation 2 devices required no special treatment of that ilk. I prefer to keep the RDEVICE section of the SYSTEM CONFIG to a bare minimum. This is not rooted in any fear of having unsupported devices on the system. Rather, it is because hardware gets moved around by a separate hardware group, sometimes without prior notice. Moving a set of devices that has been accorded special treatment in the System Config could break two sets of devices. And it would definitely not be done at a time that was convenient for me. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij > Sent: Wednesday, July 23, 2008 2:08 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Interpreting Trace > > Without having any knowledge about either the device or CP... > and no doubt this is obvious to most, but may be confusing > for some. The two highlighted phrases are not related. > The "invalid address" is from the trace itself. It is normal > to have the 07 and 0F with a data length 1, but CP concludes > the address of 0 makes no sense and does not display any data > for that I/O in your trace. > The "I/O error" is the device unable or unwilling to do what > the channel program asked for, it is not the result of the > fact that the trace sees no data to dump along with the status. > > The evidence is here, where I have no I/O error, but indeed > invalid data address. > TRACE TYPE IO, CPU TIME 09:52:19.730408 > TRACEID = TAP, TRACESET = NULL, IODATA = 32 > USER = RVDHEIJ, I/O OLD PSW = 033C 801DE7A8 > DEVICE = 0180, SCSW = 00C04007 000C8428 0C01 > ESW = 0080 >-> CCW(1) = 0721 , CCW ADDRESS = 000C8420 > ** INVALID DATA ADDRESS ** > > I believe it is also normal for tape unit to present an I/O > error upon unload (with intervention required since unloading > the tape means there is no tape mounted anymore). The device > would have no other convenient way to mention that to CP. I > do not think a rewind is rejected because of BOT. > > I'm a bit troubled by your sense byte 2 at X'24' that says > the ACL is active in auto or system mode. The ACL in auto > mode is a bit of a hack. Since the next cartridge will be > loaded from the ACL, there is no intervention required and I > suppose the unload will just take a while to complete and > then present the unit read and BOT. This means the unit must > not present device end before the next one is loaded. > > You've been vague in what hardware is involved. If this is > actual 3480 hardware, then I'm suspicious about the > autoloader. Because VM does not really support the > autoloader, it is often set in "auto" mode. > That means that the unload will also cause a reload of the > next cartridge from the autoloader (unlike MVS that actually > steers the ACT through a Load Display). > > We had major problems in the past, and were already planning > to replace the full bank of 3480s to fix it, like IBM did at > another account (with no success). The real cause turned out > to be CA Dynam/T telling the I/O operators to mount a > specific active volume on *any* unit they liked (unlike MVS > that gives specific mount request). So they were looking > around for a unit that was unloading, and put the active tape > there. But when that was in "auto" mode the ACL jammed and > the unit went not-ready. It was most common when a VSE job > was coded with incorrect options. It would take a scratch > tape from the ACL, write to it, unload it, and ask for it > a
Re: Interpreting Trace
But Sir Rob the Plumber, even the old 3420 drives had internal incandescent lights in the tape path to shine on the reflector. No need for external light to reflect on the strip! One might only presume that the hardware manufacturer of this pseudo virtualized tape drive has installed virtualized LEDs (using less virtualized electricity than old-fashioned virtualized incandescent bulbs, important in this "green" day and age) to shine on a virtualized reflector strip? ;-) But that of course begs the question of whether this virtualized tape drive might have problems with their virtualized vacuum columns (for which some manufacturers used light bulbs to detect tape location, too!)? Or... didn't Richard say way back at the beginning of the thread that this was a virtualized 3490? Never mind! :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Rob van der Heij" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 07/23/2008 10:47 AM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Interpreting Trace On Wed, Jul 23, 2008 at 5:33 PM, Mike Walter <[EMAIL PROTECTED]> wrote: > Say... could it be that the virtualized silver tape reflector fell off the > beginning or end of the virtualized tape? And are you sure that the > virtualized silver tape reflector is on opposite edges of the shiny surface > of the virtualized tape media? I can't remember which edge gets the leading > and trailing silver tape reflectors. You'll have to ask your hardware > supplier to experiment with opposite edges. ;-) But Sir Mike! The modern 3480 cartridge does not do shiny bits anymore. After all, the cartridge is closed so there is no light that will go in to shine ;-) The control unit is smart enough to count the operations that move the tape, and indeed... virtualizes BOT. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Interpreting Trace
Richard, Perhaps the DETACH command with the LEAVE option might avoid the REWIND/UNLOAD problem with this device. Mike Rydberg Brocade -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, July 23, 2008 10:23 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Interpreting Trace Thank, Alan. Your analysis confirms my faded memories of the channel and device protocols. I will pass the information on. Actually, there is no BOT and there is no tape. The vendor chose to reply like a tape drive to the roll-call for reasons unknown to me. I speculate that it is because tape units can be written to and read from in a successive operations. If that is the case, they could have chosen an old printer that allows one to read the print buffer. And they respond unconditionally to sense commands as though the device were at BOT. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Tuesday, July 22, 2008 6:11 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Interpreting Trace > > On Tuesday, 07/22/2008 at 01:57 EDT, "Schuh, Richard" > <[EMAIL PROTECTED]> > wrote: > > TRACE TYPE IO, CPU 0005 TIME 16:28:05.323115 > >TRACEID = T670, TRACESET = NULL, IODATA = 128 > >USER = SYSTEM, I/O OLD PSW = 0704D001 8000 > 002C0FBE > >DEVICE = 0670, SCSW = 01C04017 00AA4088 0E01 ** > I/O ERROR > > ** > > >ESW = 0080 > >I/O PRIORITIES: CHANNEL = 0, CURRENT = 255, ORIGINAL = 255 > > OUT-PRIORITIZED COUNT = 0 > > -> CCW(1) = 0761 , CCW ADDRESS = 00AA4080 > >** INVALID DATA ADDRESS ** > > -> CCW(2) = 0F21 , CCW ADDRESS = 00AA4088 > >** INVALID DATA ADDRESS ** > > > The vendor says that the device has been modified to return > Device End > for both > > the Rewind (CCW Op Code 07) and the Rewind and Unload (0F) > commands. > > In > the > > penultimate entry, you can see that there is a Rewind chained to a > Rewind and > > Unload. Both of those CCWs are flagged in the trace as > having invalid > data > > addresses. This is puzzling because the I/O was generated by CP. If > there are, > > indeed, invalid data addresses, sould that not cause a > Channel Program > Check or > > some other error rather than Command Reject? Why is CP using invalid > channel > > programs in the first place? > > Those are control operations. The address and length fields > are not [supposed to be] used by the device. The channel > does not generate UNIT CHECKs and does not manufacture SENSE > data. The 'invalid data address' is the result of a > determination by CP, not the channel subsystem, at the time > the record was cut. I've seen this when CP puts bad > addresses in CCWs specifically to catch unexpected data > transfer attempts. > > > Here is the pertinent section from the OPERATOR console: > > > > 15:47:21 TAPE 0670 DETACHED RSCHUH 0670 BY > RSCHUH > > 15:47:21 HCPERP500I TAPE 0670 AN OPERATION WAS TERMINATED BECAUSE > A > > 15:47:21 HCPERP500I COMMAND REJECT ERROR > OCCURRED > > 15:47:21 HCPERP6300I SENSE DATA FORMAT = 02 MSG CODE = > 00 > > 15:47:21 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = > 07 > > 15:47:21 HCPERP6303I SENSE = 80482427 0020 > > > 15:47:21 HCPERP6303I 0F01 > > > 15:47:21 HCPERP6304I IRB = 01C04017 00AA4088 0E01 > 0080 > > 15:47:21 HCPERP6305I USERID = > SYSTEM > > 15:47:21 HCPERP2216I CHANNEL PATH ID = > 52 > > 15:47:21 HCPERP2220I PHYSICAL CHANNEL PATH ID = > 0168 > > > > According to the vendor, their internal trace shows that > their machine > received > > the Rewind and responded with Device End. The next thing > they saw was > the Sense. > > The first 4 bytes of SENSE data (80482427) show that > - X'80': The device is rejecting the REWIND > - X'48': Drive is online and is at beginning-of-tape. > - X'24': Path 2 to the device is raising the error >: The autoloader has cartridges in it > - X'27': Error recovery action = (what you see in the HCPERP messages) > > Byte 7 says it is format X'20' sense data, so starting at byte 24: > - X'0F': ESCON 4.5 MB/s channel > - X'01': Autoloader is installed > > With no knowledge of the device, I'd say they rejected the > REWIND because > it was already at BOT, but regardless, the evidence points to > the device, > not to the channel or CP. > > Alan Altmark > z/VM Development > IBM Endicott >
Re: Interpreting Trace
On Wednesday, 07/23/2008 at 11:24 EDT, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > Actually, there is no BOT and there is no tape. The vendor chose to > reply like a tape drive to the roll-call for reasons unknown to me. I > speculate that it is because tape units can be written to and read from > in a successive operations. If that is the case, they could have chosen > an old printer that allows one to read the print buffer. And they > respond unconditionally to sense commands as though the device were at > BOT. Tapes are, IMO, the easiest kind of device to emulate. It's a streaming data programming model, with no annoying pre-defined data structures. (Even though a modern drive has block numbers, those are "just" for fast indexing.) Alan Altmark z/VM Development IBM Endicott
Re: Dirmaint New Install Testing Question.
T.Y. >>> Scott Rohling <[EMAIL PROTECTED]> 7/23/2008 10:08 AM >>> No you don't have to worry about DIRMSAT for sure.. DATAMOVE only if you want DIRMAINT to copy/resize/clean disks for you.. (I recommend DATAMOVE!) Scott Rohling On Wed, Jul 23, 2008 at 8:02 AM, Howard Rifkind <[EMAIL PROTECTED]> wrote: We just activated Dirmaint and gone thru the first section of the Dirmaint program directory and are up to the point of testing the installation. I have completed the testing of Dirmaint which looks O.K. The Testing the Installation procedure now takes you on to verifying DIRMSAT and DATAMOVE. We will only be using the Dirmaint system on one z/VM system and will not have any multiple system CSE clusters etc. The questions is; do I have to run thru the procedures to test DIRMSAT and DATAMOVE? And if so how do I get around the multiple system cluster issue. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Z/VOS - separate topic for MS Windows in CMS
Me too...but don't ask why??? Do you know if there will be a free eval available? How do we get our hands on a copy? T.Y. >>> Bob Heerdink <[EMAIL PROTECTED]> 7/23/2008 10:25 AM >>> I just wanted to more clearly define this exciting topic per Gary Dennis = "In Q1 2009 Mantissa will deliver a system that permits unaltered Windows= operating systems to run under z/VM." I'm keenly interested is an understatement, Bob _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Interpreting Trace
On Wed, Jul 23, 2008 at 5:33 PM, Mike Walter <[EMAIL PROTECTED]> wrote: > Say... could it be that the virtualized silver tape reflector fell off the > beginning or end of the virtualized tape? And are you sure that the > virtualized silver tape reflector is on opposite edges of the shiny surface > of the virtualized tape media? I can't remember which edge gets the leading > and trailing silver tape reflectors. You'll have to ask your hardware > supplier to experiment with opposite edges. ;-) But Sir Mike! The modern 3480 cartridge does not do shiny bits anymore. After all, the cartridge is closed so there is no light that will go in to shine ;-) The control unit is smart enough to count the operations that move the tape, and indeed... virtualizes BOT.
Re: Interpreting Trace
I don't want our hardware folks to have to go into the bay and turn the device around or use a twisted pair to connect it. :-) Alan, When you said the error is being raised by path 2 to the device, were you referring to a chpid? The response to a query paths command shows only one path. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, July 23, 2008 8:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Interpreting Trace Say... could it be that the virtualized silver tape reflector fell off the beginning or end of the virtualized tape? And are you sure that the virtualized silver tape reflector is on opposite edges of the shiny surface of the virtualized tape media? I can't remember which edge gets the leading and trailing silver tape reflectors. You'll have to ask your hardware supplier to experiment with opposite edges. ;-) Greybeards... indeed! Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Schuh, Richard" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 07/23/2008 10:22 AM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Interpreting Trace Thank, Alan. Your analysis confirms my faded memories of the channel and device protocols. I will pass the information on. Actually, there is no BOT and there is no tape. The vendor chose to reply like a tape drive to the roll-call for reasons unknown to me. I speculate that it is because tape units can be written to and read from in a successive operations. If that is the case, they could have chosen an old printer that allows one to read the print buffer. And they respond unconditionally to sense commands as though the device were at BOT. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Tuesday, July 22, 2008 6:11 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Interpreting Trace > > On Tuesday, 07/22/2008 at 01:57 EDT, "Schuh, Richard" > <[EMAIL PROTECTED]> > wrote: > > TRACE TYPE IO, CPU 0005 TIME 16:28:05.323115 > >TRACEID = T670, TRACESET = NULL, IODATA = 128 > >USER = SYSTEM, I/O OLD PSW = 0704D001 8000 > 002C0FBE > >DEVICE = 0670, SCSW = 01C04017 00AA4088 0E01 ** > I/O ERROR > > ** > > >ESW = 0080 > >I/O PRIORITIES: CHANNEL = 0, CURRENT = 255, ORIGINAL = 255 > > OUT-PRIORITIZED COUNT = 0 > > -> CCW(1) = 0761 , CCW ADDRESS = 00AA4080 > >** INVALID DATA ADDRESS ** > > -> CCW(2) = 0F21 , CCW ADDRESS = 00AA4088 > >** INVALID DATA ADDRESS ** > > > The vendor says that the device has been modified to return > Device End > for both > > the Rewind (CCW Op Code 07) and the Rewind and Unload (0F) > commands. > > In > the > > penultimate entry, you can see that there is a Rewind chained to a > Rewind and > > Unload. Both of those CCWs are flagged in the trace as > having invalid > data > > addresses. This is puzzling because the I/O was generated by CP. If > there are, > > indeed, invalid data addresses, sould that not cause a > Channel Program > Check or > > some other error rather than Command Reject? Why is CP using invalid > channel > > programs in the first place? > > Those are control operations. The address and length fields > are not [supposed to be] used by the device. The channel > does not generate UNIT CHECKs and does not manufacture SENSE > data. The 'invalid data address' is the result of a > determination by CP, not the channel subsystem, at the time > the record was cut. I've seen this when CP puts bad > addresses in CCWs specifically to catch unexpected data > transfer attempts. > > > Here is the pertinent section from the OPERATOR console: > > > > 15:47:21 TAPE 0670 DETACHED RSCHUH 0670 BY > RSCHUH > > 15:47:21 HCPERP500I TAPE
Re: Interpreting Trace
Say... could it be that the virtualized silver tape reflector fell off the beginning or end of the virtualized tape? And are you sure that the virtualized silver tape reflector is on opposite edges of the shiny surface of the virtualized tape media? I can't remember which edge gets the leading and trailing silver tape reflectors. You'll have to ask your hardware supplier to experiment with opposite edges. ;-) Greybeards... indeed! Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Schuh, Richard" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 07/23/2008 10:22 AM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Interpreting Trace Thank, Alan. Your analysis confirms my faded memories of the channel and device protocols. I will pass the information on. Actually, there is no BOT and there is no tape. The vendor chose to reply like a tape drive to the roll-call for reasons unknown to me. I speculate that it is because tape units can be written to and read from in a successive operations. If that is the case, they could have chosen an old printer that allows one to read the print buffer. And they respond unconditionally to sense commands as though the device were at BOT. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Tuesday, July 22, 2008 6:11 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Interpreting Trace > > On Tuesday, 07/22/2008 at 01:57 EDT, "Schuh, Richard" > <[EMAIL PROTECTED]> > wrote: > > TRACE TYPE IO, CPU 0005 TIME 16:28:05.323115 > >TRACEID = T670, TRACESET = NULL, IODATA = 128 > >USER = SYSTEM, I/O OLD PSW = 0704D001 8000 > 002C0FBE > >DEVICE = 0670, SCSW = 01C04017 00AA4088 0E01 ** > I/O ERROR > > ** > > >ESW = 0080 > >I/O PRIORITIES: CHANNEL = 0, CURRENT = 255, ORIGINAL = 255 > > OUT-PRIORITIZED COUNT = 0 > > -> CCW(1) = 0761 , CCW ADDRESS = 00AA4080 > >** INVALID DATA ADDRESS ** > > -> CCW(2) = 0F21 , CCW ADDRESS = 00AA4088 > >** INVALID DATA ADDRESS ** > > > The vendor says that the device has been modified to return > Device End > for both > > the Rewind (CCW Op Code 07) and the Rewind and Unload (0F) > commands. > > In > the > > penultimate entry, you can see that there is a Rewind chained to a > Rewind and > > Unload. Both of those CCWs are flagged in the trace as > having invalid > data > > addresses. This is puzzling because the I/O was generated by CP. If > there are, > > indeed, invalid data addresses, sould that not cause a > Channel Program > Check or > > some other error rather than Command Reject? Why is CP using invalid > channel > > programs in the first place? > > Those are control operations. The address and length fields > are not [supposed to be] used by the device. The channel > does not generate UNIT CHECKs and does not manufacture SENSE > data. The 'invalid data address' is the result of a > determination by CP, not the channel subsystem, at the time > the record was cut. I've seen this when CP puts bad > addresses in CCWs specifically to catch unexpected data > transfer attempts. > > > Here is the pertinent section from the OPERATOR console: > > > > 15:47:21 TAPE 0670 DETACHED RSCHUH 0670 BY > RSCHUH > > 15:47:21 HCPERP500I TAPE 0670 AN OPERATION WAS TERMINATED BECAUSE > A > > 15:47:21 HCPERP500I COMMAND REJECT ERROR > OCCURRED > > 15:47:21 HCPERP6300I SENSE DATA FORMAT = 02 MSG CODE = > 00 > > 15:47:21 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = > 07 > > 15:47:21 HCPERP6303I SENSE = 80482427 0020 > > > 15:47:21 HCPERP6303I 0F01 > > > 15:47:21 HCPERP6304I IRB = 01C04017 00AA4088 0E01 > 0080 > > 15:47:21 HCPERP6305I USERID = > SYSTEM > > 15:47:21 HCPERP2216I CHANNEL PATH ID = > 52 > > 15:47:21 HCPERP2220I PHYSICAL CHANNEL PATH ID = > 0168 > > > > According to the vendor, their internal trace shows that > their machine > received > > the Rewind and responded with Device End. The next thing > they saw was > the Sense. > > The first 4 bytes of SENSE data (80482427) show that > - X'80': The device is rejecting the REWIND > - X'48': Drive is online and is at beginning-of-tape. > - X'24': Path 2 to the device is raising the error >: The autoloader has cartridges in it > - X'27': Error recovery action = (what you see in the HCPERP messages) > > Byte 7 says it is format X'20' sense data, so starting at byte 24: > - X'0F': ESCON 4.5 MB/s channel > - X'01': Autoloader is installed > > With no knowledge of the device, I'd say they rejected the
Re: Interpreting Trace
Thank, Alan. Your analysis confirms my faded memories of the channel and device protocols. I will pass the information on. Actually, there is no BOT and there is no tape. The vendor chose to reply like a tape drive to the roll-call for reasons unknown to me. I speculate that it is because tape units can be written to and read from in a successive operations. If that is the case, they could have chosen an old printer that allows one to read the print buffer. And they respond unconditionally to sense commands as though the device were at BOT. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Tuesday, July 22, 2008 6:11 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Interpreting Trace > > On Tuesday, 07/22/2008 at 01:57 EDT, "Schuh, Richard" > <[EMAIL PROTECTED]> > wrote: > > TRACE TYPE IO, CPU 0005 TIME 16:28:05.323115 > >TRACEID = T670, TRACESET = NULL, IODATA = 128 > >USER = SYSTEM, I/O OLD PSW = 0704D001 8000 > 002C0FBE > >DEVICE = 0670, SCSW = 01C04017 00AA4088 0E01 ** > I/O ERROR > > ** > > >ESW = 0080 > >I/O PRIORITIES: CHANNEL = 0, CURRENT = 255, ORIGINAL = 255 > > OUT-PRIORITIZED COUNT = 0 > > -> CCW(1) = 0761 , CCW ADDRESS = 00AA4080 > >** INVALID DATA ADDRESS ** > > -> CCW(2) = 0F21 , CCW ADDRESS = 00AA4088 > >** INVALID DATA ADDRESS ** > > > The vendor says that the device has been modified to return > Device End > for both > > the Rewind (CCW Op Code 07) and the Rewind and Unload (0F) > commands. > > In > the > > penultimate entry, you can see that there is a Rewind chained to a > Rewind and > > Unload. Both of those CCWs are flagged in the trace as > having invalid > data > > addresses. This is puzzling because the I/O was generated by CP. If > there are, > > indeed, invalid data addresses, sould that not cause a > Channel Program > Check or > > some other error rather than Command Reject? Why is CP using invalid > channel > > programs in the first place? > > Those are control operations. The address and length fields > are not [supposed to be] used by the device. The channel > does not generate UNIT CHECKs and does not manufacture SENSE > data. The 'invalid data address' is the result of a > determination by CP, not the channel subsystem, at the time > the record was cut. I've seen this when CP puts bad > addresses in CCWs specifically to catch unexpected data > transfer attempts. > > > Here is the pertinent section from the OPERATOR console: > > > > 15:47:21 TAPE 0670 DETACHED RSCHUH 0670 BY > RSCHUH > > 15:47:21 HCPERP500I TAPE 0670 AN OPERATION WAS TERMINATED BECAUSE > A > > 15:47:21 HCPERP500I COMMAND REJECT ERROR > OCCURRED > > 15:47:21 HCPERP6300I SENSE DATA FORMAT = 02 MSG CODE = > 00 > > 15:47:21 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = > 07 > > 15:47:21 HCPERP6303I SENSE = 80482427 0020 > > > 15:47:21 HCPERP6303I 0F01 > > > 15:47:21 HCPERP6304I IRB = 01C04017 00AA4088 0E01 > 0080 > > 15:47:21 HCPERP6305I USERID = > SYSTEM > > 15:47:21 HCPERP2216I CHANNEL PATH ID = > 52 > > 15:47:21 HCPERP2220I PHYSICAL CHANNEL PATH ID = > 0168 > > > > According to the vendor, their internal trace shows that > their machine > received > > the Rewind and responded with Device End. The next thing > they saw was > the Sense. > > The first 4 bytes of SENSE data (80482427) show that > - X'80': The device is rejecting the REWIND > - X'48': Drive is online and is at beginning-of-tape. > - X'24': Path 2 to the device is raising the error >: The autoloader has cartridges in it > - X'27': Error recovery action = (what you see in the HCPERP messages) > > Byte 7 says it is format X'20' sense data, so starting at byte 24: > - X'0F': ESCON 4.5 MB/s channel > - X'01': Autoloader is installed > > With no knowledge of the device, I'd say they rejected the > REWIND because > it was already at BOT, but regardless, the evidence points to > the device, > not to the channel or CP. > > Alan Altmark > z/VM Development > IBM Endicott >
Z/VOS - separate topic for MS Windows in CMS
I just wanted to more clearly define this exciting topic per Gary Dennis "In Q1 2009 Mantissa will deliver a system that permits unaltered Windows operating systems to run under z/VM." I'm keenly interested is an understatement, Bob
Re: Dirmaint New Install Testing Question.
No you don't have to worry about DIRMSAT for sure.. DATAMOVE only if you want DIRMAINT to copy/resize/clean disks for you.. (I recommend DATAMOVE!) Scott Rohling On Wed, Jul 23, 2008 at 8:02 AM, Howard Rifkind <[EMAIL PROTECTED]> wrote: > We just activated Dirmaint and gone thru the first section of the > Dirmaint program directory and are up to the point of testing the > installation. I have completed the testing of Dirmaint which looks O.K. > > The Testing the Installation procedure now takes you on to verifying > DIRMSAT and DATAMOVE. > > We will only be using the Dirmaint system on one z/VM system and will not > have any multiple system CSE clusters etc. > > The questions is; do I have to run thru the procedures to test DIRMSAT and > DATAMOVE? > > And if so how do I get around the multiple system cluster issue. > > Thanks. > > > > > _ > LEGAL NOTICE > Unless expressly stated otherwise, this message is confidential > and may be privileged. It is intended for the addressee(s) only. > Access to this E-mail by anyone else is unauthorized. > If you are not an addressee, any disclosure or copying of the > contents of this E-mail or any action taken (or not taken) in > reliance on it is unauthorized and may be unlawful. If you are not an > addressee, please inform the sender immediately, then delete this > message and empty from your trash. >
Re: Nice idea in blog: Should we toss x86 architecture - NOT.
Gary, if it runs native windows, will it also then run x86 linux? That seems to be one of the barriers for us, that z/linux may not support certain x86 linux applications. Thanks, Mary Anne > Gary M. Dennis wrote: > > Z/VOS is a CMS application. The glass-side user will only see Windows via >> RDC and know nothing of or about CMS or VM. >> >> Gary >> >> On 7/22/08 8:30 PM, "dave" <[EMAIL PROTECTED]> wrote: >> >> >> Good luck, Gary. I do hope your organization can pull this >>> off. VM-ers need more employment possibilities:-) >>> >>> I gather from some of your previous posts to this list that >>> your Windows support software, z/VOS, is in fact a >>> sophisticated CMS-based application, that is a user would >>> log onto a CMS user id to start his Windows systemis my >>> understanding correct? >>> >>> Thanks and have a good one. >>> >>> DJ >>> - Original Message - >>> From: "Gary M. Dennis" <[EMAIL PROTECTED]> >>> To: IBMVM@LISTSERV.UARK.EDU >>> Subject: Re: Nice idea in blog: Should we toss x86 >>> architecture >>> Date: Tue, 22 Jul 2008 13:02:33 -0500 >>> >>> >>> This was our post to the zd net blog. "Maybe we already have. In Q1 2009 Mantissa will deliver a system that permits unaltered Windows operating systems to run under z/VM. Using a desktop appliance running RDC, users will be able to connect to their virtual Windows images running in the VM environment. Goodbye desktop hardware, remote maintenance, high power consumption, machine order lead time. z/VOS began with the observation that most Windows workstations do practically nothing 95% of the time and we were so intrigued with the idea of being able to actually run an intel-based operating system under IBM VM that we never looked back. VM provided a natural platform for development of this product. The product has been a bear for the development group but the thought of being able to run 3000 copies of Windows on one System z so fascinated the team that we needed very little additional incentive. Let's hope IBM can ramp up System z production." Why wait until 2016? --. .- .-. -.-- Gary Dennis Mantissa Corporation On 7/22/08 11:14 AM, "Bob Heerdink" <[EMAIL PROTECTED]> wrote: http://blogs.zdnet.com/perlow/?p=9183 > > "Should we toss x86 architecture and wipe the slate with > something greene r > and more scalable?" > > "Windows Server 2016 128-bit edition running virtualized > on z/VM in a gre en > datacenter, accessed via my house from a thin client > over high-speed fibe r > optic connection. I can see it now." > > Hope this happens sooner than predicted, > Bob > > >>> >> >>
Dirmaint New Install Testing Question.
We just activated Dirmaint and gone thru the first section of the Dirmaint program directory and are up to the point of testing the installation. I have completed the testing of Dirmaint which looks O.K. The Testing the Installation procedure now takes you on to verifying DIRMSAT and DATAMOVE. We will only be using the Dirmaint system on one z/VM system and will not have any multiple system CSE clusters etc. The questions is; do I have to run thru the procedures to test DIRMSAT and DATAMOVE? And if so how do I get around the multiple system cluster issue. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: 3590 tape drive support Z/VM
Could you please provide more information about what you would like help with. The topic is rather broad; do you need assistance with the hardware, the tape manager, or the backup software? Peter -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of R. Khalid Sent: July 23, 2008 07:17 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: 3590 tape drive support Z/VM Need some help that how to to use ATL 3590 for VM volume back up. Regards The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
Re: SUSE Linux Enterprise Server 10 SP2 Starter System for IBM System z
> Samples are just that, samples, not Holy Writ from ${DIETY}. You can,
of
> course, choose to do anything you like.
Well, as the author, I rather like the idea of saying "let us turn to
chapter 2 of the Gospel of Installation"... 8-) YMMV.
The idea with the 15x separation was to have a small /boot separate
from the bulk of the other parts, and encourage the use of a separate
/home. The setup in the sample is the base we use for most of our
installs, and it's proven to be fairly flexible for different purposes.
What we're trying is to establish a set of basic conventions on how
things are done that start from field-tested practice. I don't want to
prevent you from doing whatever you want, but the default should be
usable for reasonably large ranges of useful.
> Whenever possible, I prefer to have those two volumes only be used for
the
> operating system itself. Any add-on products, such as WebSphere,
etc., or
> applications, would be installed in separate file systems created from
a
> different LVM volume group, using different physical volumes.
This is good practice in any case. The default setup works well with
this philosophy, and it's common good practice in the Unix world.
(Mother's First Law in action...)
Re: Nice idea in blog: Should we toss x86 architecture - NOT.
Ok, so reality check folks before y'all start drooling about jobs and can think you can run 47000 windows servers under VM. In Linux we learned that running compiled code "natively" on "z", megahertz is megahertz and a CPU intensive task would always run faster on Intel than on "z" (until we got z9 and z10). And that is "native" meaning the programs were compiled to run on z, and the operating system was compiled to run on z. So now, under CMS, this emulates intel. So megahertz is NOT megahertz. With emulating an architecture, one could easily imagine losing an order of magnitude. Thus a windows server that is running at 10% peak on a 4Ghz processor would consume a z10 IFL and want more. One does need to pay significant attention to the performance characteristics before thinking about something like this seriously. Sorry. Gary M. Dennis wrote: Z/VOS is a CMS application. The glass-side user will only see Windows via RDC and know nothing of or about CMS or VM. Gary On 7/22/08 8:30 PM, "dave" <[EMAIL PROTECTED]> wrote: Good luck, Gary. I do hope your organization can pull this off. VM-ers need more employment possibilities:-) I gather from some of your previous posts to this list that your Windows support software, z/VOS, is in fact a sophisticated CMS-based application, that is a user would log onto a CMS user id to start his Windows systemis my understanding correct? Thanks and have a good one. DJ - Original Message - From: "Gary M. Dennis" <[EMAIL PROTECTED]> To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Nice idea in blog: Should we toss x86 architecture Date: Tue, 22 Jul 2008 13:02:33 -0500 This was our post to the zd net blog. "Maybe we already have. In Q1 2009 Mantissa will deliver a system that permits unaltered Windows operating systems to run under z/VM. Using a desktop appliance running RDC, users will be able to connect to their virtual Windows images running in the VM environment. Goodbye desktop hardware, remote maintenance, high power consumption, machine order lead time. z/VOS began with the observation that most Windows workstations do practically nothing 95% of the time and we were so intrigued with the idea of being able to actually run an intel-based operating system under IBM VM that we never looked back. VM provided a natural platform for development of this product. The product has been a bear for the development group but the thought of being able to run 3000 copies of Windows on one System z so fascinated the team that we needed very little additional incentive. Let's hope IBM can ramp up System z production." Why wait until 2016? --. .- .-. -.-- Gary Dennis Mantissa Corporation On 7/22/08 11:14 AM, "Bob Heerdink" <[EMAIL PROTECTED]> wrote: http://blogs.zdnet.com/perlow/?p=9183 "Should we toss x86 architecture and wipe the slate with something greene r and more scalable?" "Windows Server 2016 128-bit edition running virtualized on z/VM in a gre en datacenter, accessed via my house from a thin client over high-speed fibe r optic connection. I can see it now." Hope this happens sooner than predicted, Bob
Re: Moving SFS user
Dave, Thanks for your idea but we do not have VMBACKUP. Mary Dave de Noronha wrote: Mary, If you have VMBACKUP then use that to restore the User to the new system...it will restore all data, authorisations etc...I have used it many times to restore whole filespaces when consolidating SG2 and never had a problem
Re: SUSE Linux Enterprise Server 10 SP2 Starter System for IBM System z
I have a NCC account and am able to log onto that just fine. For some reason it just won't download the ISO files (neither SP1 nor SP2). When I click the download button it downloads a file of 0 bytes. When I use FlashGet, that's where I see the authorization error. I can download the other related files just fine. Maybe a call to Novell support is in order. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Tuesday, July 22, 2008 4:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SUSE Linux Enterprise Server 10 SP2 Starter System for IBM System z >>> On Tue, Jul 22, 2008 at 3:47 PM, in message <[EMAIL PROTECTED]>, "Hilliard, Chris" <[EMAIL PROTECTED]> wrote: > Is anyone having difficulties downloading the ISO files? I haven't heard of anyone having problems, except for people trying to use Internet Explorer running into its 2GB size limit. > I appear to be getting some sort of authorization error... HTTP/1.1 401 > Unauthorized Do you have an NCC (Novell Customer Center) account set up? Mark Post
Re: Moving SFS user
On Wed, Jul 23, 2008 at 2:06 PM, Mary Zervos <[EMAIL PROTECTED]> wrote: > I need to move our one and only SFS user from a z/VM 4.4 system > to a z/VM 5.3 system on a new mainframe. The quickest > way I can see?.Fileserv backup the VMSYSU file pool and > send the file from the old VMSERVU 305 (data disk) to the > new VMSERVU user 305. Sound right? You really can't copy the data disk like that because the catalog info is on the other disk. You *can* take a DDR copy to identical disks on the other side. But that replaces the entire filepool, not just one user. More convenient is an SFS UNLOAD FILESPACE (to a disk file) and then SFS RELOAD that again on the other side. Rob
Re: Moving SFS user
Mary, If you have VMBACKUP then use that to restore the User to the new system...it will restore all data, authorisations etc...I have used it ma ny times to restore whole filespaces when consolidating SG2 and never had a problem
Moving SFS user
I need to move our one and only SFS user from a z/VM 4.4 system to a z/VM 5.3 system on a new mainframe. The quickest way I can see?.Fileserv backup the VMSYSU file pool and send the file from the old VMSERVU 305 (data disk) to the new VMSERVU user 305. Sound right? Thanks, Mary Zervos VM Systems Programmer Binghamton University [EMAIL PROTECTED]
Re: downloading CMS files
My personal recommendation is Filezilla. Go to sourceforge.net. It's open source, free, no commercial licensing restrictions (oh, and it works very well). With over 41,000,000 downloads at sourceforge alone, you can see it is well endorsed. Pat Downs -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Fran Hensler Sent: Tuesday, July 22, 2008 5:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: downloading CMS files Yes, the free version was for educational and personal use. But it can no longer be installed, at the the last LE version can't. It phones home and you get a screen that suggests you buy WS_FTP Home. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 "Yes, Virginia, there is a Slippery Rock" -- On Mon, 21 Jul 2008 13:03:26 -0400 Higgins, Neil S said: >I think the "free" version of WS-FTP is only free for non-commercial >use. There are plenty of freeware FTP tools for the desktop.
Re: 3590 tape drive support Z/VM
Need some help that how to to use ATL 3590 for VM volume back up. Regards
Re: Interpreting Trace
Without having any knowledge about either the device or CP... and no doubt this is obvious to most, but may be confusing for some. The two highlighted phrases are not related. The "invalid address" is from the trace itself. It is normal to have the 07 and 0F with a data length 1, but CP concludes the address of 0 makes no sense and does not display any data for that I/O in your trace. The "I/O error" is the device unable or unwilling to do what the channel program asked for, it is not the result of the fact that the trace sees no data to dump along with the status. The evidence is here, where I have no I/O error, but indeed invalid data address. TRACE TYPE IO, CPU TIME 09:52:19.730408 TRACEID = TAP, TRACESET = NULL, IODATA = 32 USER = RVDHEIJ, I/O OLD PSW = 033C 801DE7A8 DEVICE = 0180, SCSW = 00C04007 000C8428 0C01 ESW = 0080 -> CCW(1) = 0721 , CCW ADDRESS = 000C8420 ** INVALID DATA ADDRESS ** I believe it is also normal for tape unit to present an I/O error upon unload (with intervention required since unloading the tape means there is no tape mounted anymore). The device would have no other convenient way to mention that to CP. I do not think a rewind is rejected because of BOT. I'm a bit troubled by your sense byte 2 at X'24' that says the ACL is active in auto or system mode. The ACL in auto mode is a bit of a hack. Since the next cartridge will be loaded from the ACL, there is no intervention required and I suppose the unload will just take a while to complete and then present the unit read and BOT. This means the unit must not present device end before the next one is loaded. You've been vague in what hardware is involved. If this is actual 3480 hardware, then I'm suspicious about the autoloader. Because VM does not really support the autoloader, it is often set in "auto" mode. That means that the unload will also cause a reload of the next cartridge from the autoloader (unlike MVS that actually steers the ACT through a Load Display). We had major problems in the past, and were already planning to replace the full bank of 3480s to fix it, like IBM did at another account (with no success). The real cause turned out to be CA Dynam/T telling the I/O operators to mount a specific active volume on *any* unit they liked (unlike MVS that gives specific mount request). So they were looking around for a unit that was unloading, and put the active tape there. But when that was in "auto" mode the ACL jammed and the unit went not-ready. It was most common when a VSE job was coded with incorrect options. It would take a scratch tape from the ACL, write to it, unload it, and ask for it again. The tape setup folks would spot the thing unloading at that moment, and pushed it back in, jamming the ACL that was busy loading the next scratch cartridge from the stack. We put in a lot of work to fix JCL not to unload tapes that were needed again, and kept a few units with ACL-off for mounts of active tapes (even if that meant tape ops had to take it from one unit to the next). Rob
