Re: FTP and BFS
Richard I read and read again the doc and I found and tested the standard translate table through the openvm mount command. That does the work like FTP with binary option. During the transfer I cut/pasted one that was finished to move it in an other windows folder... All the others transfers failed in a rc=686 I did all the work again without touching anything and all worked perfectly. As you said, it's a brittle methid... Thanks Alain Le 22 oct. 2010 à 15:40, Richard Troth a écrit : The syntax you indicate for the BFS stage is wrong. Did it get pasted into the message incorrectly? You can FTP to/from BFS just fine. I forget off the top of my head just how to activate it. You can mount NFS filesystems into a BFS tree. I have used that for years. It is really teriffic. When you mount the filesystem, you must pay attention to whether or not character set translation is in effect. I ALWAYS turn it on or off for the whole hierarchy being mounted. (There is a list option, which I believe is the default, where translation can be applied based on the filename. it gets messy.) DO NOT use NFS for general file transfer. It looks appealing. But it has never worked well. The design of the network filesystem protocols has never been tuned for bulk transfer. This has nothing to do with the implementation, CMS or some other. The underlying NFS protocol is not well suited to heavy content transport. -- R; On Fri, Oct 22, 2010 at 02:56, Alain Benveniste a.benveni...@free.fr wrote: Hi, I'm looking for a way to reduce a step to send a file. The long method is : pipe tape ! a a a1 then use FTP in binary mode to send it to windows The short method I would like to see it working : pipe tape ! bfs a a a1 (avoid to create file to use FTP) to send it to NFS I tried many options like doing a openvm mount with translate posix and adding a a 'specs 1-* 1 x0d15 n' before the bfs step. I have a set input/output off too. But the structure of the output files when comparing them is not the same. Any idea ? Alain
Re: How to determine SYSRES
In a single PIPE: PIPE (endchar ?), | LITERAL CP Q ALLOC ALL , | CP, | TAKE LAST 1 , | SPECS W6 1 , |l:LOOKUP W1, | DROP FIRST 1, | CONSOLE, ?, LITERAL QUERY CPOWNED, | CP, | SPEC W2-*, |l: Frank M. Ramaekers Jr. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Ackerman Sent: Tuesday, November 09, 2010 10:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: How to determine SYSRES 'PIPE CP Q ALLOC ALL' , '| TAKE LAST 1' , '| CONSOLE' , '| SPECS W6 1' , '| VAR sysres' , '| CP QUERY CPOWNED' , '| PICK W2 == /'sysres'/' , '| SPECS W2-* 1' , '| CONSOLE' This won't work. You cannot set the REXX variable and use it in the same pipe. 'PIPE CP Q ALLOC ALL' , '| TAKE LAST 1' , '| CONSOLE' , '| SPECS W6 1' , '| VAR sysres' 'PIPE CP QUERY CPOWNED' , '| PICK W2 == /'sysres'/' , '| SPECS W2-* 1' , '| CONSOLE' Not tested. But then the first pipe wasn't tested either. Alan Ackerman _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: How to determine SYSRES
Not tested. But then the first pipe wasn't tested either. Au contraire mon ami. My first Pipe was tested, albeit not quite correctly. I had used a home-grown REXX EXEC to test it. Until QUIT is entered, the REXX EXEC repeatedly prompts for a rexx command, executes it, and continues to prompts again. I didn't believe that using a rexx variable would work either, not even inside a rexx exec. But I had recently re-learned that inside a pipe one can read an existing stem, make changes, use the BUFFER stage, and then re-write the same stem name. I re-learn more every day. So I wondered if recent changes to Pipes might let me use a variable as part of the processing, after all, the Piper is very clever. I again re-learned that it is not possible because when rexx interprets that pipe command, the variable has not yet been set, and will still be an uninitialized variable when processed at its second reference in the pipe. But that REXX EXEC provided a quite surprise. The first time I entered that erroneous Pipe command, the results were as expected: it did not work. But it silently set the sysres variable before failing. Not realizing that the sysres var had been set, and not leaving the REXX EXEC prompts, I decided to try adding the 'BUFFER' stage to see if that might help the way it does when reading and writing the same stem. So I pressed the RETRIEVE PFkey, inserted the 'BUFFER' stage and pressed Enter. That time it worked perfectly. So I removed the BUFFER stage and tried again (there might have been a few other attempts that failed due to typos). It continued to work perfectly, but unbeknownst to me only because the sysres var was still set. So the tested results were posted, with me confident that I had learned something new. After Richard replied that it could not work, I tried again so that I could show a console list of it working. Naturally that test was doomed to failure, since the command was copied and pasted from the post (with no typos). But it worked when I pressed the RETRIEVE PFkey and pressed Enter again, unchanged! WTH!!??? It took a couple minutes for the proper synapses to fire before I understood why. :-) Moral of the story: ah... you figure it out - consider it a learning experience. The corrected, complete pipe was posted November 4: pipe cp q alloc all | take last | cons | spec /q dasd/ 1 w-1 nw | cp | pick w3 == /CP/ | cons Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Alan Ackerman alan.acker...@bankofamerica.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 11/09/2010 10:22 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: How to determine SYSRES 'PIPE CP Q ALLOC ALL' , '| TAKE LAST 1' , '| CONSOLE' , '| SPECS W6 1' , '| VAR sysres' , '| CP QUERY CPOWNED' , '| PICK W2 == /'sysres'/' , '| SPECS W2-* 1' , '| CONSOLE' This won't work. You cannot set the REXX variable and use it in the same pipe. 'PIPE CP Q ALLOC ALL' , '| TAKE LAST 1' , '| CONSOLE' , '| SPECS W6 1' , '| VAR sysres' 'PIPE CP QUERY CPOWNED' , '| PICK W2 == /'sysres'/' , '| SPECS W2-* 1' , '| CONSOLE' Not tested. But then the first pipe wasn't tested either. Alan Ackerman 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: How to determine SYSRES
True, but you can use the value in another cp command that you construct in the Pipe (tested): 'PIPE CP Q ALLOC ALL' , '| TAKE LAST 1' , '| CONSOLE' , '| SPECS /QUERY DASD/ 1 W-1 NW' , '| CP', '| LOCATE / CP /', '| CONSOLE', '| SPECS W2 1 WRITE W5 1', '| VAR IPLDEV', '| DROP 1', '| VAR IPLVOL' There is no need for more than 1 invocation of Pipes or for multi-stream Pipes. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Ackerman Sent: Tuesday, November 09, 2010 8:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: How to determine SYSRES This won't work. You cannot set the REXX variable and use it in the same = pipe. Not tested. But then the first pipe wasn't tested either. Alan Ackerman
Re: How to determine SYSRES
This pipe below can never work as the author apparently expected, whatever the piper might implement 'PIPE CP Q ALLOC ALL' , '| TAKE LAST 1' , '| CONSOLE' , '| SPECS W6 1' , '| VAR sysres' , '| CP QUERY CPOWNED' , '| PICK W2 == /'sysres'/' , '| SPECS W2-* 1' , '| CONSOLE' Just think a bit. It is a REXX EXEC, so REXX is reading the source lines, and replaces all variables by their contents (or the uppercased variable name). In the case above: only 'sysres' is outside the quotes and replaced by whatever value it has at that time. All lines (but the last) end with a , so REXX joins it to the presvious string with 1 blnk in between. When REXX built this long string (from the 9 source lines), it sees it is not an assigment, not an IF, So it passes the string to the current address (those that know me a bit know that I tell it should better be COMMAND). So the CMS command processor starts the PIPE command, and it gets this long string to handle. PIPE simply cannot know that part of the PICK parameters ever were a runtime variable. And, there is even a second error: the second CP stage. It will first pass QUERY CPOWNED as command to CP, and then the records it finds in its input stream. In this case the 6th word of the last line of Q ALLOC. I guess your IPL volser is not labeled LOGOFF ... you would have been very surprised ... -- Kris Buelens, IBM Belgium, VM customer support
Re: How to determine SYSRES
I have a local mod to CP that I originally got from Melinda Varian thru
VMSHARE, (that I have maintained thru all the versions/releases of VM
since), that adds an extra line to the reponse from QUERY CPLEVEL, (for
Class E users), that display the IPL, CheckPoint, and Warm Volsers and
Addresses. The output looks like this:
query cplevel
z/VM Version 5 Release 4.0, service level 1002 (64-bit)
Generated at 2010-09-22 15:15:16 EST
IPL at 2010-11-07 03:45:01 EST
SYSIPL=VMSY02(5B00), SYSCKP=VMSY01(5700), SYSWRM=VMSY02(5B00)
IBM could easily add this same info. The IPL Volume information is store
d
in HCPSYSCM and can be retrieved and displayed with a REXX Exec, (assumin
g
you have Class E or the equivalent CP Privilege class. Here is sample
Exec that does this. (This is not a fully roubust Exec with all the erro
r
checking/messages built-in. That is left as an exercise to the reader!
:-) It should work for most people.)
/**/
/*SYSRES EXEC */
/* Display the VM System IPL Volume Volser and Address from HCPSYSCM. */
/**/
SYSRES:
Address COMMAND
Parse Source . ctype ename etype emode .
Numeric Digits 12
eol = '15'x
asysvold = '60.6'/* Offset.Length of SYSRES Volser */
asysdvno = '730.2' /* Offset.Length of SYSRES Device Address */
locsyslc = 'LOCATE SYMBOL HCPSYSLC'
cpver= C2D(SubStr(Diag(00),11,1))
If cpver 4 Then
display = 'DISPLAY HLS'
Else
display = 'DISPLAY HS'
Parse Value Diagrc(08,locsyslc) With rc cc . . asyscm .
If rc \= 0 Then Exit rc
Parse Var asysvold offset '.' length .
dispcmd = display||D2X(X2D(asyscm) + X2D(offset))'.'length
Parse Value Diagrc(08,dispcmd) With rc cc . sysvold . (eol) .
If rc \= 0 Then Exit rc
sysvold = X2C(sysvold)
Parse Var asysdvno offset '.' length .
dispcmd = display||D2X(X2D(asyscm) + X2D(offset))'.'length
Parse Value Diagrc(08,dispcmd) With rc cc . sysdvno . (eol) .
If rc \= 0 Then Exit rc
Say 'SYSIPL='sysvold'('sysdvno')'
Exit 0
--
Dale R. Smith
Re: How to determine SYSRES
Are my posts not getting through, is the list not sending everything on the same day it is sent, or are members responding to old posts before reading all the way through the posts to see if there are already corrections? OK, so I had a bad day on 4 Nov 2010 when I posted that erroneous piece of code. Richard Schuh replied within minutes, pointing out a different problem. I responded by re-posting with Richard's fine suggestion in a slightly different way. Then on 9 Nov Alan Ackerman said what I had posted originally back on 4 Nov would not work for the reasons of the variable usage. That was true, but since a different solution had been posted late 4 Nov I did not elaborate on the variable problem back then. Earlier today 10 Nov, I explained why the use of the variable had seemed to work when I actually did test it before the erroneous post back early on 4 Nov. Hasn't this particular horse been beaten to death for long enough by now? Can we claim it dead and buried? The red blush on my cheeks faded over a week ago, c'mon already - give me a break! :-( Dale Smith's post on this subject is an altogether better solution anyway. One should expect that critical DASD volume information that was used during an IPL would be displayed as a documentary I-level message during IPL anyway. Some of this is already displayed, but a clean, concise display of the volsers and rdev of the sysres, checkpoint, warmstart, directory, parm disk, and the cylinder extents of each (even the sysres since it could be a 2nd level system) would be useful diagnostic information in the console log at a later date. Some of that is already available in various messages (displayed as they are discovered), but a single set of messages, perhaps in response to a command would be useful when things go bump in the dark. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Kris Buelens kris.buel...@gmail.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 11/10/2010 01:37 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: How to determine SYSRES This pipe below can never work as the author apparently expected, whatever the piper might implement 'PIPE CP Q ALLOC ALL' , '| TAKE LAST 1' , '| CONSOLE' , '| SPECS W6 1' , '| VAR sysres' , '| CP QUERY CPOWNED' , '| PICK W2 == /'sysres'/' , '| SPECS W2-* 1' , '| CONSOLE' Just think a bit. It is a REXX EXEC, so REXX is reading the source lines, and replaces all variables by their contents (or the uppercased variable name). In the case above: only 'sysres' is outside the quotes and replaced by whatever value it has at that time. All lines (but the last) end with a , so REXX joins it to the presvious string with 1 blnk in between. When REXX built this long string (from the 9 source lines), it sees it is not an assigment, not an IF, So it passes the string to the current address (those that know me a bit know that I tell it should better be COMMAND). So the CMS command processor starts the PIPE command, and it gets this long string to handle. PIPE simply cannot know that part of the PICK parameters ever were a runtime variable. And, there is even a second error: the second CP stage. It will first pass QUERY CPOWNED as command to CP, and then the records it finds in its input stream. In this case the 6th word of the last line of Q ALLOC. I guess your IPL volser is not labeled LOGOFF ... you would have been very surprised ... -- Kris Buelens, IBM Belgium, VM customer support 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: How to determine SYSRES
Most likely someone waking up from a long nap and looking at digests instead of e-mail. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Wednesday, November 10, 2010 12:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: How to determine SYSRES Are my posts not getting through, is the list not sending everything on the same day it is sent, or are members responding to old posts before reading all the way through the posts to see if there are already corrections? OK, so I had a bad day on 4 Nov 2010 when I posted that erroneous piece of code. Richard Schuh replied within minutes, pointing out a different problem. I responded by re-posting with Richard's fine suggestion in a slightly different way. Then on 9 Nov Alan Ackerman said what I had posted originally back on 4 Nov would not work for the reasons of the variable usage. That was true, but since a different solution had been posted late 4 Nov I did not elaborate on the variable problem back then. Earlier today 10 Nov, I explained why the use of the variable had seemed to work when I actually did test it before the erroneous post back early on 4 Nov. Hasn't this particular horse been beaten to death for long enough by now? Can we claim it dead and buried? The red blush on my cheeks faded over a week ago, c'mon already - give me a break! :-( Dale Smith's post on this subject is an altogether better solution anyway. One should expect that critical DASD volume information that was used during an IPL would be displayed as a documentary I-level message during IPL anyway. Some of this is already displayed, but a clean, concise display of the volsers and rdev of the sysres, checkpoint, warmstart, directory, parm disk, and the cylinder extents of each (even the sysres since it could be a 2nd level system) would be useful diagnostic information in the console log at a later date. Some of that is already available in various messages (displayed as they are discovered), but a single set of messages, perhaps in response to a command would be useful when things go bump in the dark. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Kris Buelens kris.buel...@gmail.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 11/10/2010 01:37 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: How to determine SYSRES This pipe below can never work as the author apparently expected, whatever the piper might implement 'PIPE CP Q ALLOC ALL' , '| TAKE LAST 1' , '| CONSOLE' , '| SPECS W6 1' , '| VAR sysres' , '| CP QUERY CPOWNED' , '| PICK W2 == /'sysres'/' , '| SPECS W2-* 1' , '| CONSOLE' Just think a bit. It is a REXX EXEC, so REXX is reading the source lines, and replaces all variables by their contents (or the uppercased variable name). In the case above: only 'sysres' is outside the quotes and replaced by whatever value it has at that time. All lines (but the last) end with a , so REXX joins it to the presvious string with 1 blnk in between. When REXX built this long string (from the 9 source lines), it sees it is not an assigment, not an IF, So it passes the string to the current address (those that know me a bit know that I tell it should better be COMMAND). So the CMS command processor starts the PIPE command, and it gets this long string to handle. PIPE simply cannot know that part of the PICK parameters ever were a runtime variable. And, there is even a second error: the second CP stage. It will first pass QUERY CPOWNED as command to CP, and then the records it finds in its input stream. In this case the 6th word of the last line of Q ALLOC. I guess your IPL volser is not labeled LOGOFF ... you would have been very surprised ... -- Kris Buelens, IBM Belgium, VM customer support 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.
BRP
Finally, the powers that be are considering remote shadowing of DASD as the way to handle the BRP situation. The time we are allotted to recover the system has been reduced to a number that is impossible using tape backups. I would appreciate it if anyone who is already doing this would regale me of their experiences - what they are doing, what are the gotchas, how satisfied are they, etc. It undoubtedly is different depending on the dasd vendors so here is what we have: * EMC DASD - about half of our DASD. * HDS DASD - the other half. * Currently, there is no SCSI, it is all ECKD We currently have no IBM DASD; however, that does not mean that we will not have some in the future. Every couple of years, we go through a DASD refresh, at which time we may change vendors. I will gladly accept replies on or off list. TIA. Regards, Richard Schuh
Re: BRP
Richard, We're using disk replication on HDS DASD for disaster recovery. We were able to reduce a script that had about 30 steps to one that isn't much more complicated than: 1. Suspend replication 2. IPL 3. Answer one question: is this a test or a real disaster? 4. Certify The test or real disaster answer determines the network configuration. DR tests are behind a firewall, so they use different OSA's than we would use for a real disaster. The answer can also be used for other things, such as determining which guests are started. We don't start z/Linux guests automatically during DR tests, because our Linux security product has a problem with two guests having the same name. If the DR guest refreshes keys or whatever it does with Active Directory, the production guest loses access. This seems to happen around midnight, so we start up DR guests when we're ready to test and shut them down as soon as we're done. One of our Linux people could explain this much better than I can. Make sure that your CP maintenance is current. We had a CP abend and guest I/O errors when we resumed replication on a z/VM 5.4.0 RSU 0801 or 0802 (I forget which) system. The problem went away when we upgraded to RSU 1001 plus some additional service. We have two copies of the disks in our DR site. This allows us to continue replicating production on the secondary disks while we test on the tertiary disks. Dennis In all matters of opinion, our adversaries are insane. -- Mark Twain From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Wednesday, November 10, 2010 16:51 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] BRP Finally, the powers that be are considering remote shadowing of DASD as the way to handle the BRP situation. The time we are allotted to recover the system has been reduced to a number that is impossible using tape backups. I would appreciate it if anyone who is already doing this would regale me of their experiences - what they are doing, what are the gotchas, how satisfied are they, etc. It undoubtedly is different depending on the dasd vendors so here is what we have: * EMC DASD - about half of our DASD. * HDS DASD - the other half. * Currently, there is no SCSI, it is all ECKD We currently have no IBM DASD; however, that does not mean that we will not have some in the future. Every couple of years, we go through a DASD refresh, at which time we may change vendors. I will gladly accept replies on or off list. TIA. Regards, Richard Schuh -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
