Yahoo Mail Spam Filters Block Efforts to Help Fight Spam

I was wondering if any one else has had this problem. Over the past couple of weeks I've had issues with Yahoo mail blocking my admittedly small efforts to fight spam. Every day I'd forward the messages in my spam folder to organizations like SpamCop.net, spam@uce.gov, and coldrain.net. However this past week or two I'm only able to forward maybe one or two messages a day before it started to block me from doing so with the following message:

Your message was not sent

Your account has been temporarily blocked from sending messages. This block can be caused by sending messages that trigger our spam filters, or by having too many recipients in one email. We encourage you to review the contents and recipient list of your message, and try sending it at after an hour or two. Doing so will usually resolve the matter.
If you are still unable to send messages after a 24-hour period, please read our FAQ for more information and to request Customer Care assistance.

We apologize for the inconvenience.

Thanks,

The Yahoo! Mail Team

Of course I've contacted "The Yahoo! Mail Team" multiple times and I've changed my password. So far nada and now the problem is starting up on another Yahoo mail account that I forward spam messages from.

This issue is especially problematic with SpamCop because after 24 hours the timestamps in the headers of the spam messages become stale and SpamCop won't process them, so I end up deleting most of them. It's a sad irony that my endeavors to help in this fight against spam are being thwarted by the very Yahoo feature that is itself trying to protect email users by identifying spam sources within Yahoo mail. While I totally understand the purpose of this effort and applaud the work being done; In my case it's overreaching and needs to be tweaked in some way. Possibly if the the application could look at the recipient email list to see if they're being sent to spam fighting organizations first before deciding whether or not to block the account.

Update (10/25/2010): After resolving the issue way-back-when the problem has re-appeared.

Update (4/4/2011): After throwing up my hands and giving up I tried again a month later and the problem went away completely. Now I have a new problem with Yahoo Classic. It keeps fouling up the send saying "There was a problem! Not sure why, but our usually-reliable server goofed-up while sending this message. Please try again." and I try again and it doesn't work. Or if it does get sent it will fail to allow me to delete the email saying "There's a problem viewing this message. Are you trying to access a message that's been moved or deleted? Try going to the folder it's in (e.g., Inbox, Trash) and selecting the message from there. If you've tried this, and relaunching Yahoo! Mail doesn't work either, feel free to contact Customer Care about Error Code 4."

Enterprise Extender PTFs Again

Once again the list of v5.4 Enterprise Extender recommended PTFs has left off some important patches. MF47274 & MF47275 can cause HPR-IP controllers to remain in an unusable VARY ON PENDING state, and varying them off and on again doesn't fix it.

Our lord Ib'm should have added MF47838 & MF47839 to the list. (Note that MF47838 supersedes MF47275). However there is still a problem because sometimes IPLing or restarting the system from a restricted state causes the controllers to again remain in a VARY ON PENDING state. Fortunately, this time it can be fixed by varying them off and then on again. Not a show-stopper, just an annoyance.

Ib'm support tells me there are two test PTFs that will resolve that problem too and they're in the process of granting me access to them. My advice to the users of HPR-IP controllers is to ignore MF47274, MF47838, and MF47839 until these test PTFs become available.

(Please see the comments for updates.)

Linux Desktop for AS/400 Developers

This is a very cool idea: Linux Desktop for IBM i Users

Brother Cozzi's "Top Ten RPG IV Requirements"

Recently Brother Bob Cozzi, the eminent leader of the RPGers Order,  published a list he called the Top Ten RPG IV Requirements. I would like to respond to that list and proffer some of my own:

1. %JOBLOG(): While I have the greatest respect for Brother Cozzi this requirement leaves me feeling,... feh. Our lord Ib'm saw fit to provide us with the QMHSNDPM API and I've been using it so long I know the parameters by heart.
2. %CONCAT(): I can see this being kind of useful, kind of like the sprintf() function from the "C" run-time cannon, but there is a difficulty when it comes to numeric fields. What if you want some to keep the leading zeros. It seems to me that it would be easier to just string everything together in a character expression.
3. %GETENV and %PUTENV: Great idea. Don't know why our Lord Ib'm hasn't implemented these built-ins yet. They would be very useful. What's the difference between this and using the Unix "getenv" and "putenv" functions to do the same thing? [Thanks to Father Klement for reminding me about these two functions as I had completely forgotten about them.]
   
4. %STDOUT: What's the difference between this and using the Unix "open" with the "read" and "write" functions to do the same thing? Am I missing something? (And by the way, what's wrong with switching to embedded SQL? I've been doing it now for a number of years and I love the fact that if you add a field to a record format you don't have to recompile everything.)
5. %REGEX: Can't really comment 'cause I haven't used the APIs yet.
6. %TOLOWER and %TOUPPER: This already exists and it's really easy. Two named constants and the %XLATE() built-in and you're done. I can't imagine our Lord Ib'm wasting his time on this.
7. Native Support for UTF8 (ASCII): This is a good one. I'd love to have a CCSID keyword to identify the data in the field and the internal support to convert the data as it's being moved into or out of the field.
8. 3rd-party Add-On Library Support: Great for developers, but I suspect that the vast majority of AS/400 programmers like myself won't care too much.
9. Reclamation; of columns 1 to 7 in free format syntax: I don't mind the /free and /end-free requirement or the loss of columns 1 to 7 as I too use it to mark changed code. What has always bugged me is the requirement that the executable code ends at column 80. It's a 100 byte line and we should be able to use its full length if we want to. In free-format languages one isn't restricted to the end point of the file, so why should free-format RPG be that way too.
10. Port RPG IV to Windows 7 and Mac OS X and Linux: Great idea as it will expose the followers of those false religions to the beauty of iSeries worship.

---

My top ten: 

1. Free format everything in RPG including the "D" and "F" specs and remove the end-of-line restriction at column 80.
2. %LEN and %DECPOS should be compile-time BIFs when the parameter is a single field. (When the parameter is an expression they can revert to being run-time BIFs.) I've got some routines where there are more named constants specifying %LEN and %DECPOS than local variables.
3. Null Terminated Fields: I'd go further on item number 7 in Brother Cozzi's list by asking for an additional keyword that identifies a character field as null terminated. Every time you use it or change it the compiler would automatically handle the null terminator. 
4. Expand *JOBRUN date formats: Currently restricted to *MDY, *DMY, *YMD, and *JUL. They should be expanded to *EUR, *USA, *ISO, *JIS, *LONGJUL, etc., which would also require the O/S folks in Rochester add these values to the DATFMT attribute of the job. I can't tell you how many times I've had to write code to get around this restriction in full date processing in an international environment. 
5. Expand date functionality to include date formats required by such things as email headers, RSS, *DTS (internal date format for message fields), etc. The learning curve on the MI instructions and/or Unix API's for them all was daunting.
6. Fix Data Display Problems in Debug: In debug, displaying the data at the end of a passed pointer has always had problems. I've got code all over the place where a structure pointer has been passed and it points to a space that contain pointers to other structures and the debug facilities in WDSCi and the green screen can't display the data they point to because of the underlying design of debugging data stored in the program object.
7. Multi-dimensional arrays: Every other language I've ever worked with has had the facility for arrays with more than one index. How is it that RPG has survived all of these years with one index?
8. Dynamic arrays: Many of us have written service programs that allow an RPG program to expand the size of an array on request and I think it's time that the RPG compiler got this feature. Instead of being a fixed size stored in the program it would be an allocated heap space. If I was designing this feature I'd add a new parameter to the DIM keyword that allows *EXPAND or *FIXED along with the dimension that would constitute the space allocated initially. Whenever a program specified an index that was out of bounds the run-time functions would simply re-allocate the space.
9. Parameter signatures in RPG procedures (aka Procedure Overloading): This would be similar to what is currently available in O-O languages like Java and C++. We can do this with SQL UDFs, so why not with RPG procedures? This would also make it a lot easier to interface with C++ procedures. It would also be nice to not have to use *OMIT and *NOPASS if you didn't want to. 
10. RPG classes: Another facet of Java and C++ that would be useful. It would also make it easier to interface with Java and C++ objects because the JNI hoops one must jump through now are too daunting to be useful.

Lord Ib'm hear my prayer, please have your minions fix the problem with READE that locks the last record in a STRCMTCTL LCKLVL(*ALL) environment. (This is the record that hasn't been read in because it's the one that caused the end-of-file condition.) This has been a permanent restriction since the System/38 days because the O/S routines that RPG is using are the ones that are locking the record. Toronto and Rochester should finally put their heads together on this one and find a solution.

New PTFs to be Tested on DEV: 08/22/09

PTFs were loaded for the following reasons:

• Recomendations:
  • High Impact Pervasive (HIPER).
• Group PTFs:
  • SF99539 (Level 108)^*: GROUP HIPER

The following PTFs were loaded for the above reasons:

5722SS1 (i5/OS):

• SI35859:
  • SE38501: OSP-DB-OTHER-RC4-MSGSQ30082 SQ30082 RC4 IS RETURNED ON DRDA
  • SE38440: OSP-DB UNNAMED COLUMN DRDA PROBLEM

---

^* -Loading this group did not result in any new PTFs being installed (they were already applied individually to our systems on previous IPLs), so only the level number was changed.

What are Lilian Days?

If you've ever used the CEEDATE() or CEEDAYS() API's on the iSeries you know that they both reference a parameter called "Lilian Days". In case you're curious, it's named after Aloisius Lilius who was an adviser to Pope Gregory XIII and an important developer of the Gregorian Calendar.

What I found most interesting (in the geeky sense) is that the concept of Lilian Days was invented by an Ib'm high priest named Bruce G. Ohms when his article "Computer Processing of Dates Outside the Twentieth Century" was published in the Ib'm Systems Journal, Volume 25, in 1986.

HTTP Group PTF SF99114 level 19 is Released on the Heels of Level 18.

Group PTF levels don't come out all that often. The HIPER group is every two weeks, but the other groups are every couple of months at least. Whenever a new version of a group PTF comes out on the heals of an earlier version it usually means that the high priests in Mecca (aka Rochester, MN) are correcting some kind of unforeseen problem. Sometimes they add a new PTF but more often than not they remove some PTF's. Always without explanation.

Last Friday our Lord Ib'm came out with level 18 of the V5R4 HTTP group PTF SF99114 and yesterday they issued level 19. In so doing they removed two PTF's from the group: 5722DG1-SI35431 and SI35432. The PTFs haven't been PE'ed, but I'm not sure whether or not I'm going to install them. On the one hand these two PTFs update the Apache server to the latest level (2.0.63) and fix a security problem (CVE-2008-2939). On the other hand it might cause other problems that our Lord Ib'm has seen fit not to reveal to us.

Recommended PTFs for Enterprise Externder is Incomplete.

The list of V5R4 recommended PTFs for Enterprise Extender (EE) is incomplete. I had to open a PMR with the minions of our Lord Ib'm because the old testament SNA communiation controllers on our development coding system failed to connect to the production systems, so we were unable to use SAVRSTOBJ.

The support priest sent me the complete list of recommended PTFs for EE and we were missing three PTFs. I have since confirmed that those were probably the three that we needed because after applying them the systems are again able to communicate using the old protocol.

When I checked I found that the EE list noted above wasn't up to date. I've sent feedback to the keepers of the web site, but as a courtesy I thought I'd post the complete list here as well:

PTF	Release	Cumulative Tape	Modules
MF40235	540	7107	*HPRIP ctlr with exchange ID defined will not vary on and SDLC XID has problem if HPR=*YES.
MF43629	540	8305	*HPRIP ctlr with exchange ID defined will not vary on.
MF42291	540	8183	DLUR and HPRIP controllers go vary on pending after Activate instead of VARIED ON, CPA58D1. MSCP changed to allow DLUR to recover on VTAM deactivate or activate.
MF42499	540	8057	NETWORK ID ALWHPTWR and HPR are *YES, ICF applications fail w/CPF5535, jobs remain in a UNKNOWN state. Sequence of BAD XID network frames case EE to be improperly initialized with invalid controller's values.
MF42587	540	8057	EE HPRIP controller remains in VaryOnPending status with no XID's being sent out.
MF45692	540	1000	EE using HPR and RTP receives timeout error. application joblogs show CPF5355. APPN&SrcSink shows RTPburst timer did not expire AND EE/HPR CONNECTION STALLS AND NO DATA IS SENT
MF44200	540	8305	EE endnode unable to locate a CICS region on ZOS LPAR
MF43891	540	8305	LDLC remains in a reset status, LatePrenegotiation XID does not send a NULL XID on its own.
MF45851	540	1000	HPR config is active, but active connections lock up, When you vary off APPC *HPRIP controllers and vl 07000C1F occurs, the process to activate PTF. An IPL will be needed to reset error condition. AND EE/HPR stops sending data when incoming stream data packet missing
MF46217	540	1000	EE task may block streams on gate before error is sent back
MF46237	540	1000	Vary On HPRIP CTL fails after IPL, XID does not complete
MF44897	545	8305	DLUR and HPRIP controllers go vary on pending after Activate instead of VARIED ON, CPA58D1. MSCP changed to allow DLUR to recover on VTAM deactivate or activate.
MF45170	545	9104	NETWORK ID ALWHPTWR and HPR are *YES, ICF applications fail w/CPF5535, jobs remain in a UNKNOWN state. Sequence of BAD XID network frames case EE to be improperly initialized with invalid controller's values.
MF44262	545	8305	*HPRIP ctlr with exchange ID defined will not vary on.
MF45881	545	9104	HEA fc181X and Virtual Ethernet fc268C lossing data in UDP layer
MF46122	545	8305	NETWORK ID ALWHPTWR and HPR are *YES, ICF applications fail w/ CPF5535 and will now accept retransmitted frames in BIND.
MF43329	545	8183	Partition/system crash with srcB6005121 on vary of EE controller
MF44072	545	8183	EE HPRIP controller remains in VaryOnPending status with no XID's being sent out
	545	do not order - test status	MF44344 - EE/HPR ICF application fails. CPF5107 E015 unbind received RTP did not check for this error
MF46366	545	1000	Vary On HPRIP CTL fails after IPL, XID does not complete
MF46218	545	1000	EE task may block streams on gate before error is sent back
MF46063	545	1000	APPC using HPR/EE gets RTP timeout
MF46064	545	1000	EE endnode unable to locate a CICS region on ZOS LPAR

IBM PE's seven PTFs for V5R4.

While my pastoral duties at this community are normally rather dull, my favorite activity is working with the most holy code (i5/OS) and PTFs (Parchment Temporary Fixes). I especially love it when I find an error in the code that causes the cardinals and bishops in Rochester to do something drastic.

A couple months ago, as part of a HIPER recommendation, we installed PTF 5722SS1-SI34484. The following Monday morning the BACKUP job was looping forever waiting for an HTTP server job to end. We didn't associate it with the PTF right away because this isn't the first time the backup got held up by something like this. By the time we'd figured out that this was a trend we'd already installed another HIPER recommendation, PTF 5722SS1-SI34576, which superceded the one installed previously.

So we were now stuck in an untenable situation. We couldn't remove the PTF and we didn't want to reload the O/S. Being in this kind of pickle can really focus the mind. I ended up writing a program that detected these zombie HTTP server jobs and killed them with ENDJOBABN.

The minions of our Lord Ib'm eventually discovered that a thread in the HTTP job was prematurely destroying the list of open files. The job would then sit there forever waiting of the files to close not knowing that that list was gone. In the end they had to PE a bunch of PTF's and since two of them were HIPER recommendations the fixing PTF (SI35317) was also made a HIPER.

Final tally was seven PE'ed PTFs and one HIPER, all from one PMR.

Some Source to Download

A colleague of mine has posted some programmer tools on his web site. Just click on the above link. The functions include service programs for Dynamic Arrays, Subfile Control, and Message Subfile Control. He's also included an example program that illustrates using the latter two service programs.