> -----Original Message----- > From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On > Behalf Of Thomas David Rivers > Sent: Friday, November 13, 2009 3:46 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: weird(?) idea for an extended symlink functionality > > John, > > You could use a program to do this, and a named pipe. > > To simplify this a little... if you had a program that wanted > to open the file INFILE. And, it wanted a concatenation of > FILE1, FILE2 and FILE3. (And, let's say the program is > named 'prog') > > Then - a typical UNIXy approach would be: > > cat FILE1 FILE2 FILE3 > INFILE > prog INFILE > > (assuming 'prog' took the name of its input file as a parm). > > OK - that's well and good. > > But - you say - that's lousy, as it keeps the file "INFILE" lying > around and lacks a certain "sense of being easily configured." > And the 'cat' program doesn't really feel like PDS concatenation. > > One nice approach to solving this dilema in UNIX-land is with a > "named pipe"; that is created with the 'mkfifo' command. > > So - you might have: > > mkfifo INFILE > prog INFILE > > The file "INFILE" is not a file at all, but a "pipe". > The program, 'prog' is sitting there, waiting to read it's > input from INFILE pipe. (Of course, 'prog' isn't strictly > aware of this, it simply reads from the named file.) > > Now, we have _another_ process that starts to write the > concatenation to INFILE. > > cat FILE1 FILE2 FILE3 > INFILE > > That program is `cat' in this example; but it could be something > much more "fancy" that did any number of "act like a PDS > concatenation" > tricks. > > > There are some advantages to this approach. > > 1) The producer ( `cat' in our example ) can become > a more complicated program. It can become a program > that, for example, reads "DD definitions" from some > configuaration file, or environment variables, and > processes those in any arbitrary fashion to create > the desired data. > > 2) The program ( `prog' in our example ) does not have to > be altered in any fashion. It simply reads as it always > does. > > 3) The producer program can now work for any program > that reads input (not just the one in our example.) > This division-of-labor is a fundamental design tenant > in UNIX. > > 4) The UNIX kernel does not need to be extended/altered. > > 5) The same facility is available on other OSs > (see http://en.wikipedia.org/wiki/Named_pipe for other > examples.) > > Some disadvantages: > > 1) You've gotta know the name of the pipe. (Of course, > a program has to know the DD name on z/OS and/or a > file name on UNIX.) > > 2) You have to 'manage' the pipe (create it and delete it). > > > Just thought I would throw out another approach, that can be tackled > on your existing system. > > - Dave Rivers -
Another interesting idea. I might implement it as: pipe=/tmp/pipe1.$$; mkfifo ${pipe}; cat ${FILES} >${pipe} &; prog ${pipe}; rm ${pipe} -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390