"Open Social Security" calculator: feature requests, bug reports, etc

Non-investing personal finance issues including insurance, credit, real estate, taxes, employment and legal issues such as trusts and wills
vtMaps
Posts: 399
Joined: Tue Oct 14, 2008 12:05 pm
Location: central Vermont

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by vtMaps » Sat Sep 29, 2018 11:06 am

Watty wrote:
Sat Sep 29, 2018 10:32 am
If you are wanted to look at the "net present value", which seems to be more relevant, instead of just the "present value" then wouldn't that $30K a year be need to be considered as a "relevant cash outflow" like you described in your description?
I think the foregone income is accounted for... isn't that what the discount rate is all about?

--vtMaps
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true. --James Branch Cabell

User avatar
ObliviousInvestor
Posts: 3384
Joined: Tue Mar 17, 2009 9:32 am
Contact:

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by ObliviousInvestor » Sat Sep 29, 2018 11:30 am

Watty wrote:
Sat Sep 29, 2018 10:32 am
I think where I am getting confused is that if I delay starting Social Security after my FRA then I would have to fund $30,000 a year from my retirement savings until I start Social Security at the recommended age of 70. If you are wanted to look at the "net present value", which seems to be more relevant, instead of just the "present value" then wouldn't that $30K a year be need to be considered as a "relevant cash outflow" like you described in your description?
There is no need for a net present value here, because there are no outflows. The closest thing to an outflow here is an opportunity cost.

If you count the $30k as an outflow in the case of delaying and you count the dollars received by filing early, you're double-counting the benefit of filing early.

Edited to add: The amount you spend per year doesn't change as a result of when you file. (Or at least, we're assuming it doesn't.) So if you want to count spending as an outflow, fine. But you have to count it in every case. That is, you'd have to count it as an outflow in the file-early scenario as well.

So you can:
1) Calculate the present value of Social Security benefits under each claiming strategy, and compare them; or
2) Calculate the NPV of "Social Security benefits minus spending" under each claiming strategy, and compare them.

Those will give the same suggestion as far as best strategy.
Last edited by ObliviousInvestor on Sat Sep 29, 2018 11:44 am, edited 2 times in total.
Mike Piper, author/blogger

User avatar
ObliviousInvestor
Posts: 3384
Joined: Tue Mar 17, 2009 9:32 am
Contact:

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by ObliviousInvestor » Sat Sep 29, 2018 11:31 am

vtMaps wrote:
Sat Sep 29, 2018 11:06 am
Watty wrote:
Sat Sep 29, 2018 10:32 am
If you are wanted to look at the "net present value", which seems to be more relevant, instead of just the "present value" then wouldn't that $30K a year be need to be considered as a "relevant cash outflow" like you described in your description?
I think the foregone income is accounted for... isn't that what the discount rate is all about?

--vtMaps
Yes, exactly.
Mike Piper, author/blogger

User avatar
Watty
Posts: 14097
Joined: Wed Oct 10, 2007 3:55 pm

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by Watty » Sat Sep 29, 2018 1:16 pm

I think I figured out a way to look at it that makes more sense to me. That is to change the way the objective is phrased from basically being;

"Find the claiming strategy with the highest present value in September of 2018."

to be;

"Find the claiming strategy with the highest preset value, including my investments, in September of 2026 when I turn 70".

This is mainly semantics but when I thought of it that way I could look at the the scenarios as they would be in 2026 and it was clearer, at least to me.

I made a simple spreadsheet that started off with a portfolio of about $120K. In the early claiming strategy the $120K in the portfolio was still available when I turned 70. The critical part that I was not seeing was that each year the present value of my remaining Social Security would decline by about $30k each year so by my 70th birthday it was $120K lower.

In the late claiming strategy about $30K was subtracted from the $120k portfolio each year but the present value was left the same. When I turned 70 the portfolio was depleted but my Social Security still had the same present value.

Anyway when I looked at it that way I could see that the combination of the portfolio and the present value agreed with the numbers from the model on the web site.

This is obviously very rough "back of the envelope" math that does not include a lot of factors including that the present value will change as the years go by.

User avatar
onthecusp
Posts: 476
Joined: Mon Aug 29, 2016 3:25 pm

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by onthecusp » Mon Oct 01, 2018 10:59 pm

What a wonderful tool, thanks for all the time and effort that has gone into it from you and the reviewers above.

I've been working with it for about a week now, and the study has filled in many points about Social Security that I have been unclear on. In particular using this together with the output from the socialsecurity.tools calculator (I used to establish estimates of our PIA) I finally understand spousal benefit.

Request: In the section on alternative mortality tables in the "About" page you provide a fine summary of the alternative tables. Could you provide an equivalent summary of the default SSA's period life table? So I can see the default male/female ages set against the alternatives.

I noticed this when I played around with alternate tables as my wife is a former smoker so I changed her table to Smoker Preferred and mine to non smoker preferred as I am in decent health. I was surprised when this changed the recommendation for my lower earning wife to take benefits later (close to FRA instead of the previous recommendation of 62+1 mo). The new recommendation lined up close to results from previous use of the old bedrock capital calculator, so I would like to explore that a little more.

Thanks!

User avatar
ObliviousInvestor
Posts: 3384
Joined: Tue Mar 17, 2009 9:32 am
Contact:

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by ObliviousInvestor » Tue Oct 02, 2018 6:07 am

onthecusp wrote:
Mon Oct 01, 2018 10:59 pm
Request: In the section on alternative mortality tables in the "About" page you provide a fine summary of the alternative tables. Could you provide an equivalent summary of the default SSA's period life table?
Good idea. That will be included the next time I roll out an update. Here's the table in question, by the way, in case it's helpful in the meantime:
https://www.ssa.gov/oact/STATS/table4c6.html
Mike Piper, author/blogger

User avatar
onthecusp
Posts: 476
Joined: Mon Aug 29, 2016 3:25 pm

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by onthecusp » Tue Oct 02, 2018 9:16 am

Yes, very helpful. Seems the SS assumptions are just a bit better than the 'smoker preferred' option. About what I would expect. I'll run some alternate scenarios again tonight and see if I still have any questions. Thanks! :D

An additional question brought on by considering our own Mortality.

In the "Year by Year Benefit Amounts" section of the results display you say:
The survivor benefit amounts at the bottom of the table assume that a) the deceased person lived at least until the age at which they planned to file for their retirement benefit and that b) the surviving person waits at least until their full retirement age to file for a survivor benefit.

That makes sense, and I don't think additional calculations of alternatives etc. would be an improvement on an otherwise well laid out and simple presentation of the facts. I could probably answer my own question by trying alternative claiming strategies, but directionally, the question is:

What should I tell my wife to do if I die before FRA? In other words I violate (a)) above :x .

We want to maximize the survivor benefit so (b)) above should be followed. She just turned 62 and her PIA is about 1/3 of mine. If she takes her benefit at say 62 and 4 months she is in the system. I'm 7 months younger. If I should die at say 63 will she then be deemed to have applied for the survivor benefit? That would be before her FRA and mine both and permanently reduce the benefit. Might this be another reason for her to delay claiming her benefit until my FRA? If this is a misconception, is there a simple statement you might add to the output to allay this fear, or if it is a real issue a different statement that might point out the potential benefit of delay?

User avatar
ObliviousInvestor
Posts: 3384
Joined: Tue Mar 17, 2009 9:32 am
Contact:

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by ObliviousInvestor » Tue Oct 02, 2018 9:31 am

onthecusp wrote:
Tue Oct 02, 2018 9:16 am
An additional question brought on by considering our own Mortality.

In the "Year by Year Benefit Amounts" section of the results display you say:
The survivor benefit amounts at the bottom of the table assume that a) the deceased person lived at least until the age at which they planned to file for their retirement benefit and that b) the surviving person waits at least until their full retirement age to file for a survivor benefit.

That makes sense, and I don't think additional calculations of alternatives etc. would be an improvement on an otherwise well laid out and simple presentation of the facts. I could probably answer my own question by trying alternative claiming strategies, but directionally, the question is:

What should I tell my wife to do if I die before FRA? In other words I violate (a)) above :x .

We want to maximize the survivor benefit so (b)) above should be followed. She just turned 62 and her PIA is about 1/3 of mine. If she takes her benefit at say 62 and 4 months she is in the system. I'm 7 months younger. If I should die at say 63 will she then be deemed to have applied for the survivor benefit? That would be before her FRA and mine both and permanently reduce the benefit. Might this be another reason for her to delay claiming her benefit until my FRA? If this is a misconception, is there a simple statement you might add to the output to allay this fear, or if it is a real issue a different statement that might point out the potential benefit of delay?
Deemed filing does not apply to survivor benefits.

So, in the example scenario you describe, she could continue to collect her own (reduced) retirement benefit until reaching her survivor FRA, at which point she could file for her benefit as your survivor. And her total monthly benefit at that point would be equal to your primary insurance amount.

As far as adding further guidance regarding the table output, I'm reluctant to do so. Based on emails from people using the calculator, it is apparent that the guidance currently there (three lines of text unless viewed on a mobile device) is sufficiently long that many people are already not reading it. And I suspect that adding more would compound this issue.

I do plan -- once I've finished adding the desired functionality to the calculator -- to add an "FAQ" page, with links to articles explaining various concepts.

Also just for reference, survivor benefit calculations and planning are covered in the book as well.
Mike Piper, author/blogger

User avatar
onthecusp
Posts: 476
Joined: Mon Aug 29, 2016 3:25 pm

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by onthecusp » Tue Oct 02, 2018 10:44 am

Thanks, I got lazy once I got into discussion mode here. It is pretty specific that deemed filing applies to spousal benefits and if SS does not say it applies to something else, then it does not. I agree with not cluttering up the results page, I did not read those caveats until I printed it out and reviewed our results.

As a non-expert it is easy to get spousal and survivor confused when thinking back on what one reads. Combine that with plenty of poor articles that make one question everything you read and clear accurate advice is golden.

Your book looks like the deal of the century. I'm going to buy a copy to show my wife and around the office.

User avatar
onthecusp
Posts: 476
Joined: Mon Aug 29, 2016 3:25 pm

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by onthecusp » Tue Oct 02, 2018 1:12 pm

onthecusp wrote:
Mon Oct 01, 2018 10:59 pm
I noticed this when I played around with alternate tables as my wife is a former smoker so I changed her table to Smoker Preferred and mine to non smoker preferred as I am in decent health. I was surprised when this changed the recommendation for my lower earning wife to take benefits later (close to FRA instead of the previous recommendation of 62+1 mo). The new recommendation lined up close to results from previous use of the old bedrock capital calculator, so I would like to explore that a little more.
I did the comparisons and now figure that the larger estimated increase in my median age at death out weighed the smaller decrease in her's, estimating extra time where we received benefits on both our records.

Just curious, does the math treat the median ages at death as two hard stops? Something I read recently pointed out that the median age at death for the second partner is higher than the median age for either one alone.

User avatar
ObliviousInvestor
Posts: 3384
Joined: Tue Mar 17, 2009 9:32 am
Contact:

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by ObliviousInvestor » Tue Oct 02, 2018 2:08 pm

onthecusp wrote:
Tue Oct 02, 2018 1:12 pm
Just curious, does the math treat the median ages at death as two hard stops? Something I read recently pointed out that the median age at death for the second partner is higher than the median age for either one alone.
For each year until both people would be age 115, the calculator calculates:
1) What the couple's total benefit would be if both people are alive,
2) What the couple's total benefit would be if only person A is alive, and
3) What the couple's total benefit would be if only person B is alive.

Then it multiplies each of 1, 2, and 3 by the applicable probability and sums the probability-weighted amounts.

And yes, the second-to-die joint life expectancy of a couple is longer than the longer of the two individual life expectancies. And the first-to-die joint life expectancy of a couple is shorter than the shorter of the two individual life expectancies. Many Social Security analyses overestimate the value of delaying for the lower earner in a couple (and underestimate the value of delaying for the higher earner) by ignoring this fact.

You may be thinking of the discussion that occurred on pages 2 and 3 of this thread:
viewtopic.php?f=10&t=258728
Mike Piper, author/blogger

User avatar
One Ping
Posts: 482
Joined: Thu Sep 24, 2015 4:53 pm

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by One Ping » Tue Oct 02, 2018 2:46 pm

Mike, a request regarding the descriptions of the mortality tables provided on your information page (Mortality Table Options).

For each of the four alternative mortality tables you provide the median age at death for 62 year old males and females. You don't provide that same information for your default table. I think it would be instructive to see how the four alternatives differ not only with respect to each other, but also with respect to the default. Can you add those numbers to your description page?

One Ping
"Re-verify our range to target ... one ping only."

User avatar
onthecusp
Posts: 476
Joined: Mon Aug 29, 2016 3:25 pm

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by onthecusp » Tue Oct 02, 2018 5:54 pm

ObliviousInvestor wrote:
Tue Oct 02, 2018 2:08 pm
onthecusp wrote:
Tue Oct 02, 2018 1:12 pm
Just curious, does the math treat the median ages at death as two hard stops? Something I read recently pointed out that the median age at death for the second partner is higher than the median age for either one alone.
For each year until both people would be age 115, the calculator calculates:
1) What the couple's total benefit would be if both people are alive,
2) What the couple's total benefit would be if only person A is alive, and
3) What the couple's total benefit would be if only person B is alive.

Then it multiplies each of 1, 2, and 3 by the applicable probability and sums the probability-weighted amounts.

And yes, the second-to-die joint life expectancy of a couple is longer than the longer of the two individual life expectancies. And the first-to-die joint life expectancy of a couple is shorter than the shorter of the two individual life expectancies. Many Social Security analyses overestimate the value of delaying for the lower earner in a couple (and underestimate the value of delaying for the higher earner) by ignoring this fact.

You may be thinking of the discussion that occurred on pages 2 and 3 of this thread:
viewtopic.php?f=10&t=258728
I was reminded of the couple's life expectancy by something linked to from your blog, which I looked at last night. Very nice. Good point about the first to die. No guarantees, but the probability is there to be considered!

That is a good discussion though, I hadn't seen it before. I had a surprisingly similar discussion with a co-worker at lunch who is convinced to take SS early due to an expectation of average market returns. It is much the same in the first post of that discussion vs. the real discount rate you recommend. I like using your assumption because it is closer to what an annuity would "pay" and using delayed filing as longevity insurance or annuity substitution. I'm not worried about my co-worker. His retirement will be ridiculously over funded compared to me.

User avatar
ObliviousInvestor
Posts: 3384
Joined: Tue Mar 17, 2009 9:32 am
Contact:

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by ObliviousInvestor » Tue Oct 02, 2018 8:41 pm

One Ping wrote:
Tue Oct 02, 2018 2:46 pm
For each of the four alternative mortality tables you provide the median age at death for 62 year old males and females. You don't provide that same information for your default table. I think it would be instructive to see how the four alternatives differ not only with respect to each other, but also with respect to the default. Can you add those numbers to your description page?
Yes, I will do this next time I roll out an update.
Mike Piper, author/blogger

User avatar
ObliviousInvestor
Posts: 3384
Joined: Tue Mar 17, 2009 9:32 am
Contact:

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by ObliviousInvestor » Wed Oct 03, 2018 1:29 pm

Per onthecusp's and One Ping's requests, the "About" page now has a brief bit of data about the default SSA mortality table, as well as a link to the table itself.

I also rolled out child benefit functionality today for users with "single" marital status. I will be starting the coding shortly for married/divorced users. (Best guess is 1 month to completion, but as always I'm very unsure about that guess.)

Also just FYI I'll likely be somewhat slow to reply over the next several days.
Mike Piper, author/blogger

User avatar
One Ping
Posts: 482
Joined: Thu Sep 24, 2015 4:53 pm

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by One Ping » Wed Oct 03, 2018 7:20 pm

ObliviousInvestor wrote:
Wed Oct 03, 2018 1:29 pm
Per onthecusp's and One Ping's requests, the "About" page now has a brief bit of data about the default SSA mortality table, as well as a link to the table itself.
Thanks, Mike. This is my go to tool for analyzing SS claiming options.
"Re-verify our range to target ... one ping only."

User avatar
onthecusp
Posts: 476
Joined: Mon Aug 29, 2016 3:25 pm

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by onthecusp » Thu Oct 04, 2018 9:04 am

Yes, now that I understand the advanced options I like it better than the defunct bedrock capital calculator that inspired Mike to start this journey.
Thanks Mike! :beer

User avatar
ObliviousInvestor
Posts: 3384
Joined: Tue Mar 17, 2009 9:32 am
Contact:

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by ObliviousInvestor » Thu Oct 11, 2018 5:58 am

Seeking some feedback here.

I'm currently working on retroactive applications, because they are especially applicable in a child benefit scenario, which is the bigger project I'm currently working on. (For background information about retroactive/backdated applications, see below.)

My question is how a user would prefer to see backdated applications in the table output. For instance, if it were currently April 2018 and the calculator suggested backdating your application to October 2017, would you find it more intuitive to see the Oct 2017-Dec 2017 benefits included in the "2017" row or in the "2018" row?

I have my own inclination, but I want to hear what others think.

For reference the suggested strategy output (i.e., the bullet points above the table) would be something along the lines of "You file for your retirement benefit to begin (retroactively), as of Month/Year."

Background regarding retroactive applications:
If you are past your FRA, when you file you have the option to backdate your application up to 6 months (but no earlier than your FRA). This is the case for retirement benefits, spousal benefits, or survivor benefits. Child benefit applications can be backdated 6 months as well. And child/spousal/survivor benefits can actually be backdated up to 12 months in certain disability-related cases.
https://www.ssa.gov/OP_Home/cfr20/404/404-0621.htm
Mike Piper, author/blogger

goblue100
Posts: 668
Joined: Sun Dec 01, 2013 10:31 am

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by goblue100 » Thu Oct 11, 2018 6:19 am

I want to join the others in thanking you for your efforts on this calculator. As to the question, it's a little hard for me to picture the difference between the two displays, but I believe I would prefer to see 2017 in its own row based on the description you gave.
Can't take it with you when you're gone | But I want enough to get there on - Rollin with the flow - Jerry Hayes

User avatar
ObliviousInvestor
Posts: 3384
Joined: Tue Mar 17, 2009 9:32 am
Contact:

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by ObliviousInvestor » Thu Oct 11, 2018 6:35 am

goblue100 wrote:
Thu Oct 11, 2018 6:19 am
I want to join the others in thanking you for your efforts on this calculator. As to the question, it's a little hard for me to picture the difference between the two displays, but I believe I would prefer to see 2017 in its own row based on the description you gave.
Thank you for the comment, and thank you for the feedback.

Here's a mock-up. (Sorry for the poor job with the photo editor. Not something I have much experience with.)

Image

So, it could look like that. Or the table could begin with 2018, and the amount from 2017 could be lumped into the 2018 row.
Mike Piper, author/blogger

goblue100
Posts: 668
Joined: Sun Dec 01, 2013 10:31 am

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by goblue100 » Thu Oct 11, 2018 6:51 am

ObliviousInvestor wrote:
Thu Oct 11, 2018 6:35 am

Or the table could begin with 2018, and the amount from 2017 could be lumped into the 2018 row.
Hmm, I may change my answer, and say it should just be lumped in the 2018 row. I assume it will be obvious to the user that year included backdated payments?
Can't take it with you when you're gone | But I want enough to get there on - Rollin with the flow - Jerry Hayes

User avatar
ObliviousInvestor
Posts: 3384
Joined: Tue Mar 17, 2009 9:32 am
Contact:

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by ObliviousInvestor » Thu Oct 11, 2018 7:02 am

goblue100 wrote:
Thu Oct 11, 2018 6:51 am
I assume it will be obvious to the user that year included backdated payments?
Well, the suggested strategy output will include the word "retroactive." But whether or not the meaning of the table will be obvious to the user is one of my concerns.

My personal leaning is for there to be a 2017 row for a few reasons:
1) The coding will probably be easier,
2) It matches the convention the table uses so far, of showing the period for which a benefit is received rather than period in which a benefit is received (e.g., if a person files in December of a given year, there would be a benefit amount for that year shown in the table, even though the benefit wouldn't actually be received until January),
3) I think it is more intuitive.

#2 is the primary reason for my view, as this convention is the norm in Social Security conversations in general.

But #3 is just my personal opinion. And I'm hoping to get some feedback as far as whether other people agree or disagree. (Again, thanks for taking the time.)
Mike Piper, author/blogger

goblue100
Posts: 668
Joined: Sun Dec 01, 2013 10:31 am

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by goblue100 » Thu Oct 11, 2018 8:00 am

No problem, hopefully some people will wake up and you will get some other opinions soon. :happy

I wonder if the solution might not be to include a "Retroactive" or "Back Dated" row, and lump the backdated payments there? I'm thinking of a case where I'm filing in March, and 2017 has 3 months of back dated payments and 2018 has 3 months?
Can't take it with you when you're gone | But I want enough to get there on - Rollin with the flow - Jerry Hayes

User avatar
FiveK
Posts: 5572
Joined: Sun Mar 16, 2014 2:43 pm

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by FiveK » Thu Oct 11, 2018 10:41 am

ObliviousInvestor wrote:
Thu Oct 11, 2018 7:02 am
2) It matches the convention the table uses so far, of showing the period for which a benefit is received rather than period in which a benefit is received
Consistency is good. For that reason, using the same logic for retroactive filing as for normal filing seems better.

One could make the case that reporting "the period in which a benefit is received" is more helpful for tax planning purposes, but that's a different question.

vtMaps
Posts: 399
Joined: Tue Oct 14, 2008 12:05 pm
Location: central Vermont

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by vtMaps » Thu Oct 11, 2018 10:58 am

FiveK wrote:
Thu Oct 11, 2018 10:41 am
One could make the case that reporting "the period in which a benefit is received" is more helpful for tax planning purposes, but that's a different question.
That would match my needs... I will start benefits in 2019, but want to avoid SS income in 2018, so I may request 6 months retroactive benefits. Speaking of which, I asked a question about that in another thread, but haven't yet received any replies: viewtopic.php?f=2&t=261110

--vtMaps
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true. --James Branch Cabell

User avatar
ObliviousInvestor
Posts: 3384
Joined: Tue Mar 17, 2009 9:32 am
Contact:

Re: "Open Social Security" calculator: feature requests, bug reports, etc

Post by ObliviousInvestor » Thu Oct 11, 2018 11:04 am

Thank you everybody for the feedback.
FiveK wrote:
Thu Oct 11, 2018 10:41 am
One could make the case that reporting "the period in which a benefit is received" is more helpful for tax planning purposes, but that's a different question.
Indeed it would be more helpful for tax planning.

To be up-front though, that is not an option I am considering. My reasoning is that I think it would be detrimental to people's understanding (in part because it goes against convention for how we typically discuss Social Security but also just because it's more complicated). In the hypothetical example I gave above (a person filing in December), the user could likely figure it out. But in more complex scenarios (application mid-year, multiple benefit types, earnings test, etc.) I am confident that it would only make it harder for people to see where the numbers are coming from. And I already get at least a few emails everyday from people having trouble with such.
Mike Piper, author/blogger

Post Reply