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 -
>
> This goes back to the person who wanted some way to emulate DD concatenatio=
> n of multiple datasets so that they are read as if they were one. Everybody=
> agrees that there isn't an easy way. Now, I don't know filesystem internal=
> s. But what about a new type of symlink? Normally, a symlink contains the r=
> eal name of the file. Sometimes a symlink will point to another symlink, an=
> d so on (I don't know how deep). What about a multi-symlink. That's where a=
> symlink points to multiple files in a specific order. When the symlink is =
> opened and read, each file in the symlink is opened and read in order. I kn=
> ow this would require some changes to open() as well, in order to make sure=
> that each file in the symlink chain is readable by the process.
>
> What think? Or is this just alien to the UNIX mindset?
>
> ln -s symlink realfile1 realfile2 /etc/fstab /tmp/somefile
>
> 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
--
[email protected] Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
----------------------------------------------------------------------
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
