Another related question is gis.stackexchange.com/questions/6476/…, which concerns the inverse of this problem (find the distance given the point). The two solutions are closely related: once the polyline is made measurable, all points along it can be addressed in terms of their distances (and arbitrary segments along it can be addressed by distance ranges).
–
whuber♦May 31 '12 at 16:05

Based on your needs, as @LouisH referred to, using Linear Referencing is definitely the way to go. I cobbled together some code that should meet your need of not hard-coding elements, but instead requesting them as parameters.

As explanation, the Linear referencing tool used below takes "Routes", in your case the line features, and places "Events", in your case the points, along them based on a distance field. This results in a FeatureLayer, which is stored in memory, which is the reason for the last function which copies the features to an output featureclass.

Edit -
One thing to think about with this tool, and likely any operation to locate points based on the distance from the end of a line, is which end of the line you will start from. The linear referencing tool, for instance, works based on the digitized direction of a line. It will be important to ensure that you have some way of identifying which endpoint your measurements are based upon.

I found this question trying to do what I think is the same thing. I wanted it all done via arcpy. Using Linear Referencing wasn't making sense to me because I don't already have the point events (and I couldn't figure out how to use LR to get them). The crux of what I ended up using was

This requires Arc 10.1 or higher; I wasn't able to figure out whether this was available below the ArcInfo licensing level I have (OP specified ArcView).

In my example above, I wanted a point not at a fixed distance, but by a percentage of the overall line length. To do this, I supplied the second optional argument to positionAlongLine. You skip the second arg if you just want to specify an absolute distance. Here's the doc.

'flFL' is my featureLayer of lines on which I want to locate the points. Runs pretty fast. NumPyArrayToFeatureClass was a very nice way to dump all my points back into a featureClass (thanks to my colleague Curtis for that part!). Had been experimenting w/Append_management but that was a fair bit slower.

+1 Thanks for sharing that. It looks like a good one-off solution when you don't want to invest the effort setting up a measured polyline. Note that this solution uses the implicit orientation of the polyline determined by the order in which its coordinates are stored. If care was not taken with that, you might wind up with points computed starting from the wrong end. Thus is would be nice to enhance this solution to enable the user (somehow) to stipulate--perhaps by means of inputting a point near one end--which is the beginning of the polyline.
–
whuber♦Jan 23 '14 at 23:46

1

That's definitely true. I'm using lines from a drainage network which are all (supposedly) oriented downstream, so I didn't have to deal with this. If the line orientation is not deliberate, it could be arranged as a pre-process to what I suggested above. If orientation is deliberate, then one could make a copy, re-orient, and use my recipe. The points will still line up on the original line featureclass properly, even if its orientation isn't conducive to the current analysis.
–
RolandJan 23 '14 at 23:54

Might be an overkill, but if you have access to Network Analysis extension you could create network from your polylines and then create service areas around your input points, specifying SA size as the distance of interest. Here is a cursory example with 111 meters SA from the point:

It seems like the problem with these options is that they require prior knowledge of the point location in order to split the line, or to add a vertice at the line prior to splitting it. That point location is what is Not known in the question above, so it is hard to apply either of these solutions.
–
Get SpatialMay 31 '12 at 15:16