> -----Original Message-----
> From: Linux on 390 Port [mailto:[email protected]] On
> Behalf Of Thomas David Rivers
> Sent: Friday, November 13, 2009 3:46 PM
> To: [email protected]
> 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
[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
