RE: how we will program in the future

| -----Original Message-----
| [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of rob@xxxxxxxxx

| How many will run safely with ever loading them?  I don't know, didn't
| read the cover letters.  Often you'll see something close to "security
| issue - just load it ".
|
| How many will run happily with ever loading them?  Probably a lot less
| than are running Windows happily without loading the more recent service
| packs.

I believe the better question is what percentage?

I'm looking at V5R2M0 cover letters Brian posted yesterday, with quick
quesses without a lotta study:

"Notice:" at top seems to indicate any of these patches could mebbe disable
Fast/400 stuff

MF31243 - problem hooking up with Windows
MF31322 - problem with SQL and IASP (Independent Aux Stg Pools)
SI10068 - problem with spooling printouts whilst job ending??  Well easy
circumvention: "Do not add spooled files to an output queue associated with
a writer if you don't intend to print them."
SI10295 - "The resolve to the QRECOVERY library for an IASP is incorrect"
SI10625 - "The STRPAGGRP limitation is 250 characters and it appears that
InfoPrint Server is truncating this limit to 80 characters. ***NOTE:  The
STRPAGGRP DDS keyword and the USRDFNDTA field in the printer file are
intended to contain only one email address, not multiple addresses."
SI10661 - "Allow 250 characters for PDF segment name from DDS"
SI10662 - Something to do with PSF writers (print SPLing)
SI10671 - "RCVJRNE code was always calling the user exit program to indicate
no more entries, even if the exit program had requested receive to halt."
SI10672 - Abstract "OSP-CERT-INCORROUT Mark Count Overflow Prevention"
Dunno?  (Same as next one.)
SI10678 - "more susceptible to a 'mark counter overflow' error than they
were in previous releases."
SI10682 - "This means that any uncommitted DB operations are commited
instead of rolled back, which is not the correct semantic and is not
consistent with the original HTTP server."

Granted, small sample size.  I don't believe you see a lotta problems
relating to "lost or corrupted data", on a 400, like you would with *nix or
Windows.  Icbw.  Same with security.  The last PTF above is interesting, as
it shows that the original HTTP server was better than Apache *in this
respect* at least.  And I have no doubt the 400 Apache is more secure than
any other flavor of Apache.

True, from follow-up post, Rob:  "And a lot of the pro/con is where your
bias lies."

But the facts are the facts and (though hard) are distinguishable from
biased opinions.  There are companies that run mission-critical apps on
*nix, Windows and CPF/OS/400.  The question, in my mind (biased to the
extent that it is), boils down to TCO.  I forget the (Gartner?) TCO numbers
I just read a few days ago:  The 400 costs x% of what "similar" Windows apps
cost to run, and y% of *nix apps.  Where x was much smaller than y, but both
were a fair bit less than 100%.

Didn't study this particular study, and whose research to you believe,
anyway??  Who does a thorough *apples to apples* comparison with the least
bias???  But my gut-feeling is also backed by several specific cases of
experience, and that's why I believe this TCO study.