[fpc-devel] Re: EBCDIC (was On a port of Free Pascal to the IBM 370)
Mark Morgan Lloyd
markMLl.fpc-devel at telemetry.co.uk
Fri Feb 3 21:58:56 CET 2012
steve smithers wrote:
>> rvmartin2 at ntlworld.com wrote on Thu, 2 Feb 2012 16:28:29 +0000 (GMT)
..
> "Write once, compile anywhere" isn't that the motto? I'm not trying to suggest
> anything to break this model, but when I compile my code on the mainframe, I
> would expect stuff like if ch in['A'..'Z'] to be EBCDIC based.
That's reasonable, but is of course an RTL issue- or if it's not an RTL
issue today I suspect it will be at the end of this port :-) However as
Tomas points out the compiler will also have internal lists of reserved
words and (pseudo-) procedures, and it might be that at present they
assume ASCII collation order.
>> Mark Morgan Lloyd <markMLl.fpc-devel at telemetry.co.uk wrote on Thu, 02 Feb 2012 17:27:51 +0000
>>
>> I'd only expect the version control system to contain textfiles. Or are
>> you saying that some IBM operating systems support files which contain
>> both text and data (I'm aware of the Mac's OS and obviously OS/2 doing
>> this, both of which FPC supports).
>
> I wasn't really talking about source files. I was talking about I/O in
> general. Translating a text file on the fly is possible, assuming you
> can identify it as such. But what about a structured file that contains
> mixed binary and string info. Integers need to converted from little to
> big endian, strings from ASCII to EBCDIC, floating point from PC to mainframe
> formats, files may contain internal pointers to other info, again it needs
> to be converted. Doing all this automagically in the RTL isn't an exercise
> in coding it's clairvoyance. And yes, MVS supports mixed binary and string
> data in a file, doesn't every operating system?
Yes, but some operating systems also support there being multiple forks
(or some comparable term) of a file, so that (for example) an executable
file contains both binary code and *separate* resource/message data,
both of which can be read sequentially starting from zero. Think two
columns in a database, both blobs.
>> Just trust me then. PC doctrine has it that anybody can write a
>> compiler, but we're aware of the fact that other architectures might do
>> things differently.
>
> Anyone can write whatever they want on the mainframe too. All the tools
> required are provided. What you do with it has nothing to do with architecture,
> it's to do with security. If you were a user on a Linux system, one amongst
> 50 others, one without root access, you would find yourself constrained about
> what you and your compiler could do. At least I hope you would.
Yes and no. An unprivileged user on Linux can compile a kernel, or can
even build a compiler which is then used to build a kernel, and the end
product would be bootable or executable. The only thing he can't do is
tell the system-wide boot manager to load the kernel at the next
startup, or put the compiler where it is executed as the system default.
Some operating systems require a special blessing or signing stage in
those cases. If IBM OS and its brethren don't, then it makes life a bit
easier.
>> No, but having an accessible operating system for testing is, and it
>> would end up being extremely inconvenient if that operating system
>> didn't support standard networking so that- at the very least- test code
>> code could be got onto it and copies of error messages got off. I don't
>> think the other developers would be happy if told they had to use
>> (something equivalent to) Kermit :-)
>
> Hercules provides terminal access to a TCP/IP client, both in 3270 terminal
> mode and for file transfer. As far as I know Kermit is not available
Hercules certainly does. MUSIC/SP (which was what was originally
suggested as a target operating system) only provided TCP/IP if run on
VM, or on Sim/390 which is Windows-only.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the fpc-devel
mailing list