> -----Original Message----- > From: Linux on 390 Port [mailto:[email protected]] On > Behalf Of Bishop, Peter > Sent: Sunday, December 13, 2009 10:25 PM > To: [email protected] > Subject: concatenating input files with named pipes > > Hi again, > > I'm moving ahead a little bit and have done some basic tests > with tapes but now have something I don't understand. > > I'm trying to "concatenate" two tapes into one named pipe, > and then read the pipe, hoping thereby to read the two tapes > at once (trying to emulate the z/OS JCL concatenation concept). > > Here's my logic, which is not working as I'll explain in a > minute. My thinking is that I can write to the pipe > sequentially and read it sequentially, but it appears not to > work that way. > > pe...@sydvs002:~> sudo dd if=/dev/rtibm0 of=pipe & > pe...@sydvs002:~> sudo dd if=/dev/rtibm1 of=pipe & > pe...@sydvs002:~> sudo dd if=pipe of=packages &
UNIX does not "enqueue" on the pipe (or even a file) the way you would expect z/OS to enqueue on a dataset. I assume you want to read from /dev/rtibm0 in its entirety and then on /dev/rtibm1, sequentially. Concurrently you want to read the pipe and output to the file packages. In the above scenariou, I would suggest doing: (sudo dd if=/dev/rtimb0 of=pipe; sudo dd if=/dev/rtibm1 of=pipe) & sudo dd if=pipe of=packages & By enclosing the first two command in parentheses, separating them with a semi-colon, you run them sequentially in a subshell. By putting the & after the closing parenthesis, you run the subshell asynchronously. This reads the tapes sequentially, not concurrently. Like a DD concatenation. You may not need to the sudo on the last command, if your normal id has write access to packages. You may not need the & on the last sudo either, unless you want to do things from the shell while the dd is writing to the packages files. And, just as an aside, if you want to read the pipe into a program, you could do that as well. Either by specifying the pipe as an input file, or by redirecting stdin to the pipe. Which is what I would guess you will eventually want to do. Note that I'm not sure that the sudo is really necessary. You could use ACLs (vaguely equivalent to RACF PERMITs) to allow the actual user to have read access to /dev/rtibm0, and/dev/rtibm1, along with read/write access to packages. Look at the setfacl command. Something like: sudo setfacl -m u:myid:r /dev/rtibm0 sudo setfacl -m u:myid:r /dev/rtibm1 sudo setfacl -m u:myid:rw package Instead of u:myid, you could allow a group with g:mygroup. And you may also issue the setfacl as many times as necessary to add all the required users and groups to the access list. If you want to see what the access list is, use the getfacl command: getfacl /dev/rtibm0 What is "nifty" is that you can direct the output of the getfacl to a file in order to save it. And, if necessary, later direct the setfacl to read that file to restore the ACLs. sudo getfacl /dev/rtibm0 >~/rtibm0.getfacl ... sudo setfacl -m - /dev/rtibm0 <~/rtibm0.getfacl > > When I do this, the first and third commands work as > expected, i.e. the contents of the first tape are copied into > the disk file "packages". The second command didn't block, > but went ahead and copied zero bytes into the disk file (it > really should have copied about 30MB, so why it didn't is a > small mystery but not as large as its not waiting for the > first command). I expected the second command to block, or > be queued behind the first command. On reflection, I decided > that expectation was wrong, i.e. there is no reason for the > second command to block as I was expecting. > > Am I right to think that I'll have to implement some sort of > queuing mechanism if I want the input files to queue into the > pipe and be read sequentially? Or have I still a basic > misunderstanding of queueing with named pipes, such that > named pipes can queue input commands in the way I'm expecting? The subshell is your "queueing mechanism". > > If I have to do my own queueing, I'm sure something simple > like cmd1 && cmd2 && cmd3 etc. will be OK, but I wanted to > make sure I've not misunderstood the available facilities first. > > thanks again for your input, > best regards > Peter > > Peter Bishop > HP Enterprise Services APJ Mainframe Capability & Engineering -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
