11am - noon: 4169 pages
Noon - 1pm: 4282 pages
Last week at this time:
11am-noon: 4681 pages
Noon - 1pm: 3311 pages
NDPSGW-3.01g-NDPS OPERATION ERROR(prhh154-2): The 208 operation to the NDPSM failed.We've had it before. This is one of three ways that the printer-agents in our pools can go unresponsive. This is also the first time I've caught one of them at this. The -704 error is probably an NDPS/NDPSM/NDPSGW error and not a DS error, much as they share the same error codes. Not 100% on that one. I'll see what I can dig out of developer docs.
If needed, the Error Codes explanations in the online System Messages documentat
ion may provide additional information about the following return codes.
Error code: -704 (0xFFFFFD40)
okay...so this band is not a 1960s, 70s or even 80s band. They began in 1994 and have released 3 or 4 CDs since then, and from what I understand, they are currently in studio recording their next CD. I don't believe they were actually one that was suggested earlier."Whoa" go I. A band I might have actually listened to as a kid. Possibly an Alt-Band.
The BrainShare 2005 conference partyâ€”to be held Wednesday, March 23, at 6:30 p.m. in the Delta Centerâ€”will feature Train, whose first album, "Drops of Jupiter," went platinum. Its title single, "Drops of Jupiter (Tell Me)," spent a total of 53 weeks on the Hot 100 before winning a Best Rock Song Grammy and Best Arrangement Grammy. Check out some of the pieces from Train's new album, "My Private Nation," on the group's Web site.Train!
- Fixed a problem when authenticating to a server with no replica. Seen by Apache and it would return error code 83.The 'no replica' issue has been with us since before the NWLIB6A patch. In fact, 6a fixed it for the most part. As you can see here, it is still something of a problem.
|Total System Memory
|File System Cache (NSS)
||Stu1, Stu3, Class1
Welcome to 2005. Remember "05" on your checks.
The cluster has survived the weekend at NW6.5. However, I'm not liking some of what I'm seeing. From some of my other servers it looks like NW6.5 is more vulnerable to memory fragmentation than NW6.0 was. We had one cluster node lock hard two days ago, which caused failovers.
One of the services that didn't completely survive was myweb for FacStaff, the webserver that serves this very blog. After looking into what went screwy, it looks like the server served pages for several hours before it started returning a "111" error. When I look up that error message, I find that it is "Generic file system error; see filesyserrno". On a previous troubleshoot of mod_edir and LibC I know that filesyserrno is an error-trapping number. In this case it is not being extracted to the logfiles, so I'm not sure what it returned. The only way I know to grab it again is to set a breakpoint, and that just isn't nice to do with a cluster-node. What it does tell me is that Something went wrong and it couldn't handle it.
This is an example of a problem in LibC, not mod_edir. LibC is the Netware library that is multi-processor aware, long filename aware, and getting more POSIXy as time moves on. The old CLib library which began live in the NW2.x products is none of these. Apache1.3 and the modules that accompany it called mod_hdirs and mod_rdirs were ported to Netware using the CLib library. This is why the Apache1.3 version of MyWeb is far more stable than the Apache2.0 (linked to LibC instead of CLib) version.
MyFiles (a.k.a. NetStorage) has survived the move to NW6.5 very well. Things are getting used, and I now have logfiles to gauge usage. Also important, since we're using Apache2.0 instead of Apache1.3 I now can use RotLogs to make sure my logfiles don't get insanely large. We've had some MyFiles outages in the NW6.0 days due to the error_log file hitting 4GB.