On Jan 12, 2008, at 1:44 PM, Paul Gilmartin wrote:
On Sat, 12 Jan 2008 12:53:03 -0600, Ed Gould wrote:
The current Major software vendors all use SMP/e(it took years of
battling to get them that way THERE is a reason). The few that don't
are not worth the effort to even look at.
SAS? (I'm thinking of their dwindling C compiler and RTL;
I don't know details of their main statistical products.)
Gil,
I don't believe SAS is a *MAJOR* software vendor. You may and as far
as I know it doesn't need AC(1). If its changed since the last time I
installed it fine, I would still think long and hard about it. The
last time I installed we installed it in its own library as it was
(at that time) I don't know if it still is a bit on the lets say
language unique from release to release. The major reason (at least
at that time) to put it in its own library for steplib purposes. We
had been burned a few times so that is how we did it. I was not the
SAS person a fellow sysprog and he seemed to bear the brunt of
changes from the SAS users. Every time he put a release in he would
get inundated with complaints about differences. He finally had to go
under change control as people were majorally PO'ed because he seemed
to break SAS with every new release. I sort of liked SAS myself, but
the users were not happy with *ANY* changes as they would have to re-
hire consultant(s) every time it "broke".
The C++ compiler needs LE (and that is already SMP/e). I have never
worked with it but since it is written by IBM I assume its smp/e. I
have no idea about runtime but I would think its in either a PDS or
PDSe from IBM and like the saying goes if its from IBM its SMP/e.
Outside of downloads direct from IBM (non-supported) products the
only NON smp/e product I have run into is IND$FILE. AFAIK every
language that IBM offers is SMP/e installable even (shudder) APL and
that was put out eons ago (over 20 years) Not that there have been
many fixes for it lately. I did run into an issue 18 years ago with
it. The APL people got me over with it. I don't remember the issue it
had to do with PSF though. COBOL all shapes and sizes have been smp/e
for at least 30 years assembler (XF) was probably (that is going way
back). I can't think of an IBM compiler that has not been (SMP/e)
installable for 20++ years. Any (compiler or COMPONENT) that is
shipped on the SERVPAC is SMPe installable. AFAIR all CA (Computer
Associates) mainframe products that run on the mainframe (AFAIK) are
SMPe installable (maintainable is *ANOTHER* issue).
Like I have said before if you are a postcard (read cheap) type
vendor you are probably not going to be SMP/e installable. I can also
name you vendors that are like that and their product usually breaks
at least once a servpac install because of a change that they are
dependent on (example col X on a LISTC output) and it shifts a byte
or two. Those types of vendors are the ones you have to end up
spending money on supporting as you tend not to get it from the
vendor. *IF* you are a 2 sysprog shop maybe you can get away with
that, I don't know in a big shop don't even try it.
I am talking about System related products that run AC(1) (or their
own SVC etc) not a payroll or user type products should be smp/e
maintainable. Here is one that should be but its freeware its QUEUE
(the precursor to SDSF). But its freeware and you get what you pay
for. A Decent product that is user supported and extremely sensitive
to JES2 changes (as it would be), support, I don't think so. If JES2
changes SDSF is automatically recompiled and 99 percent of the time
it works. The 1 percent is semi acceptable but the SDSF people have
seen most of the issues, support is good. But again you get what you
pay for with Queue.
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
