I’ve been working with ABAP programming for over 20 years, and learned something new today. I was horrified.
Today I had a lovely chat with a customer who was proudly telling me that he’d never programmed in nearly 30 years.
Me – what did you do?
Him – I was a PL1 programmer on a mainframe?
Me- really? Which OS?
Him – MVS?
Me – I did that! I did MVS and VM systems programming!
Him – ah, but this was back in the early 90s.
Me – Same as me.
… but we had work to do! (And my boss was listening…)
End of Digression
But we had a problem to solve. Why wasn’t the code we* had supplied him working? We’d just handed over the very latest release of our software, and they’d installed it in one system. Trouble was, it was being called from another system that hadn’t been upgraded.
Now, here’s the deal.
Turns out that if you call an RFC enabled FM, the parameters are handled differently from normal calls.
So, here’s the rules.
If the parameter is present and csequence then it gets padded with spaces on the right. Cool, huh? I mean who cares if it’s supposed to be ‘ABCD ‘ and you pass ‘ABCD’? Only weird old languages are using that kind of typing, and I’m calling this from… Rust? No. It makes sense because “out there” might not even be able to right pad. It might not even have that type.
If the parameter is missing, then it is supplied with the default value?. Say whut? Hold your horses!
So if I fail to pass, e.g. something typed as I, at best it’ll be supplied as 0. Well, that just seem unnatural to me. And not safe.
If you’re writing an RFC enable function module, treat every parameter as optional, and figure out how to handle it. In my situation, making it defaullt to SY-UNAME worked fine.
I don’t know though. Handling missing parameters in this way seems deeply deeply wrong. My mind isn’t twist enough to figure out how this can be exploited – I’m a very straight-forward type of man – so I’ve passed it to my boss, who’s mind is so twisted, it’s fractal. And so, so pretty.