Unix deficiencies/problems

[Scott Barman]

In article <429 at algor2.UUCP> jeffrey at algor2.UUCP (Jeffrey Kegler) writes:
>In article <676 at dtscp1.UUCP> scott at dtscp1.UUCP (Scott Barman) writes:
>=In article <424 at algor2.UUCP> jeffrey at algor2.UUCP (Jeffrey Kegler) writes:
>==I miss very little from the IBM world, but the availability of formal file
>==names is one of them.  
>=
>=Is this anything like trying to remember which utilities wants their
>=input from ddname SYSUT1 or SYSIN?  Or ourput to SYSOUT or SYSPRINT
>=or even SYSUT2?
>=
>=I do not miss anything from that world!!!!
>
>The problem of memorizing a multiplicity of names, is definitely there, but
>inherent in the problem.  Memorizing a lot of option letters, different for
>each utility, is also hard (though multi-letter options would have been nice).
> [...]
>Really what Scott is saying is that he has never come across an application
>requiring more than SYSIN, SYSOUT and SYSERR.  He probably has.  They
>certainly exist.

No, what Scott is saying is there is at least a consistancy!  The standard
input is alway the standard input and it is found at fd 0, the standard
output is always the standard output and is found at fd 1, the standard
error output is always the standard error output and is found at fd 3.
If nothing else has, this has been consistant--at least since version 6!
The problem I mentioned with the multiple names (above) are not consistant
and got very annoying and led me to have to learn to write clists (I learned
this under TSO) or I would never remember which used what.

>                               Any of you who
>have quarreled with another developer over the fact that he was putting out
>too many debugging messages, really could use a SYSLOG in addition to
>SYSERR.  
Redirect standard error--and atleast you can find it and not guess which
ddname it is using!

>         A transaction oriented environment where enough bucks are at stake
>will attract auditors who want several logs.  A lot of larger applications
>require you to declare half a dozen environment variables telling you where
>the files it wants are.
That is the deficiency of the program, not the environment it is running on.
I have found many times that these large "canned" applications have been
written by Unix "converts" who came over from the mainframe world and do
not (or have yet--at the time) the knowledge necessary to mold the ideas
properly into the environment.  Software I have seen from Unix developers
for Unix systems seems to have been well thought out as to their interaction
with the environment.  So don't judge the system when it is the fault of
the brain damaged applications!

>And are SYSIN, SYSOUT and SYSERR really harder to remember than 0, 1 and 2?
If they remained that consistant, the only problem I have is with the names.
They are not consistant with the Unix environment and I prefer to stick
with this long-time convention!

-- 
scott barman
{gatech, emory}!dtscp1!scott