Jordan Henderson wrote:
[...]
> > Not that it's an easy task, but wouldn't modifying the PerlIO abstraction
> > layer to only use RMS calls accomplish this? It would require someone
> > who really knows his XABs from his RABs, but could still be done using
> > only the available RMS interface.
> >
>
> "Not that it's an easy task". Yes, that's an understatement.
>
> Sigh... I hate to beat a dead horse, but you see, what you are
> proposing is _exactly_ what the authors of the C RTL have already
> done. Even if it's just too far out to maintain our own C RTL to
> link against, we could at least extract the relevant routines from
> the source for the existing C RTL, make necessary changes for our
> custom requirements and use these in VMS.C.
I think it depends on what you're trying to accomplish, and from
where you come. I'm a FORTRAN programmer, and make no apologies
for that. FORTRAN io is record oriented, and RMS is record
oriented, so they map well in my brain. Unix, and therefore C,
and therefore Perl, is stream oriented, and I can't stand it.
Maybe it's just me, but I've never done a fork/exec, never created
a symlink or clobbered a file. With any luck I will continue to
never fork/exec, symlink, or clobber a file. I've never called
flock because that's not my job, that's the OS' job.
What I'd like is for io operations on VMS to behave like io
operations on VMS. FORTRAN does it. Cobol does it. Basic does it.
Datatrieve does it. C doesn't, and therefore Perl doesn't.
But it should. And that's why I suggested changing the PerlIO
layer: the scope of my pet peeve is smaller than the whole CRTL.
OK. Sorry. I'm done with my rant. I feel better now.
