Re: Question Re: Piping and Redirection

Just an idea:-

Perhaps IBM could add some additional options to commands. For example,
the DSPOBJD has OUTPUT(*OUTFILE). What if it had OUTPUT(*PIPE).

Another parameter would be required to tell it where to pipe to. This
could be the name of a program, or another command capable of accepting
a stream of data.

The format of the data would not be an issue. The data is formatted for
*OUTFILE, the same format would apply to *PIPE

The disadvantage would be release to release updates. The APIs in the
system are compatible with each other across OS/400 releases. As a
result, programs that use APIs rarely need to be changed when a new
release is installed. However, programs that use outfiles or interpret
printed information from commands, do not have this luxury, and are much
more likely to require change when a new release is installed. I suspect
that programs that used any new piping interface would not be release to
release compatible.

Syd Nicholson


Dennis Lovelady wrote:

Hi, Evan:

The quick answer to your question is that the utilities can read any file
that exists on a readable filesystem within a unix system (assuming proper
authority, of course).

If I have a linux system on an Intel platform with some ext2, ext3, VFAT,
FAT and MINIX partitions (maybe throw in a couple of NFS from disparate
systems, including WIN and MAC machines), I can treat them all as equals...
every program that can read a file, can read all the files on all of those
filesystems, without regard to whether it's of a a certain type.  The
concept of treating a file differently just because it's on a different
filesystem is completely foreign to Unix, and far from what would be
considered "acceptable" in most environments.

HTH
Dennis





Evan Harris <spanner@ihug.co.nz>@midrange.com on 11/20/2002 01:31:42 AM

Please respond to midrange-l@midrange.com

Sent by:    midrange-l-admin@midrange.com


To:    midrange-l@midrange.com
cc:
Subject:    Re: Question Re: Piping and Redirection


Hi James
some responses in line...

Well that isn't how a unix person would expect it to work.  As Hans said,
cat doesn't care what the file is, it just opens it and reads it.  While I
suppose there is an argument to be made that the AS/400 way is how cat
should work (i.e. not opening files that don't make sense to show on the
display) it is inconsistent with the way cat works on every other system.
A unix person might choose to do this instead of DSPPFM:

cat /qsys.lib/mylib.lib/myfile.file/member.mbr | more

But if cat won't open the dang file that is never a possibilty.

My take is that /qsys.lib should be viewed as a different file system and
therefore we can expect some different results and behaviours. I am not as
immersed and experienced with Unix as you are so I cannot say whether every
file system accessible or mountable under unix will honour every unix
command initiated against files on that mounted file system: you or someone
more knowledgeable may be able to offer a perspective.

My knee jerk reaction is that they wouldn't , but since most of them would
be similar enough in nature- like windows - or other unixes this may not
make a difference either way. The as/400 is likely to be the odd man out
here which will make it an "as/400 thing" in the minds of those already
unable to deal with a system that can not only natively provide a unix file
system but run a "foreign" OS natively on the box :)

Before too many people clamor that the cat method is a stupid replacement
for DSPPFM, remember that there is an easy way to view new records *as
they are added* to the database using unix tools (if the AS/400 used the
tools correctly).  On unix you can do:

tail -f /the/file/you/want/to/watch

this works on binary or any type of file.  It just prints on the screen
the "tail" end of the file.  The '-f' makes new entries to the print to
the screen as they happen.  There is no way to do this on the AS/400.  You
can use DSPPFM and go to the bottom, then exit, then do it again, etc.
But it is not the same ability.  If the AS/400 let cat, tail, etc. work
like they do on other systems then what I describe above would become a
possibilty.

I have run the tail command under qshell and it worked OK although I could
not quite imagine a use for it. I am assured by my unix colleagues that it
is extremely useful but I confess to not being able to dream of an
applicable situation regarding a database file. If I really wanted to know
when a process was ended for instance I would submit a job to the job queue
to send me either a page or a break message.

I am still at a loss as to why it is useful to see records "as they are
added" to the database. My mates made exactly the same claim as you BTW and
I am no more enlightened as to what benefits this confers. Straighten me
out :)

Admittedly I was only able to run it on stream files in the IFS - IIRC I
got an operation not allowed for type of file or something similar for a
database file in /qsys.lib but as I said this makes a certain perverse
sense to me.

Hope this is interesting

Regards
Evan Harris

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.