[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