Date:         Tue, 22 Feb 2005 13:48:33 -0800
Reply-To:     cassell.david@EPAMAIL.EPA.GOV
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "David L. Cassell" <cassell.david@EPAMAIL.EPA.GOV>
Subject:      Re: X command in Mainframe
In-Reply-To:  <0E5377DC9E9CE34C98D7CDA4EE29154A024583D0@SEW01070.maple.fg.rbc.com>
Content-type: text/plain; charset=US-ASCII

harry.droogendyk@RBC.COM replied (I think to Toby):
> Platform independence only matters if it's a distinct possibility.
> If Basem will be on the real computer for the next hundred years,
> what difference does make?  One can waste a great deal of time,
> increase program complexity etc.. in over-engineering what could be
> a very simple solution, just to attain the "holy grail" of platform
> independence.

True, and yet I'll disagree a little.  :-)

I've seen way too much effort spent on portability, particularly when
the effort creates something which is anything but portable.  Like
C code.  :-)

On the other hand, I've also seen NO attention paid to portability
by people who were sure that it wouldn't be an issue, only to have it
become crucial in no time at all.  Two relevant examples are:

[1] A case very much like Basem's, where 'everyone' knew there was
no portability issue, and code very much like this was used to read
some slop out of a couple directories.. and it broke as soon as they
got two upgrades along and a tiny change was made in the CMD.EXE
output.  I *think* it was actually the DIR output.  Oops.

[2] 'Everyone' knew there was no need for portability, so the code
was built on SunOS and designed to stay on those Sun boxen forever..
and the executable broke as soon as the next OS upgrade was performed,
because Solaris and SunOS are built on different versions of unix.
Oops.

And then there are the analogous cases with SAS code.  Oops.

>               I've been in the software business for over 20 years
> ( yikes! ) and I can remember exactly one instance when code was
> ported from one platform to another without significant application
> system rewrite at the same time.

<Yorkshire accent> You were lucky! </Yorkshire accent>

I always try to work in a significant app re-write too.  They always
need it.  ;-)

> BTW, there's no indication ( aside from the vague hint of 'LIB' in
> the dataset name ) that SAS datasets are involved.  If it's anything
> but SAS datasets/catalogues, I do not see how the SAS meta data will
> be of any assistance.

True.  But SAS (or other) code can still be used to read the directory
and get all the &BLAH..sas files.  And using the API, however
implicitly,
is safer than depending on DIR never to change formats again.

David
--
David Cassell, CSC
Cassell.David@epa.gov
Senior computing specialist
mathematical statistician