develooper Front page | perl.perl5.porters | Postings from December 2021

Re: elevator pitch: ASCII version of Perl for z/OS (previouslycalled OS/390 or os390)

Thread Previous | Thread Next
Karl Williamson
December 1, 2021 18:11
Re: elevator pitch: ASCII version of Perl for z/OS (previouslycalled OS/390 or os390)
Message ID:
On 11/29/21 10:47 AM, Mike Fulton wrote:
> Hi Karl,
> I've done an initial read of the documents you mentioned. I have a 
> couple starter questions...
> If we provide 2 new 'features' (64-bit perl and ASCII perl) for z/OS, is 
> it better to:
> - create a new -D option for Configure, akin to the -Dusedl being used 
> for dynamic libraries? (e.g. -Dos390useascii and -Dos390use64 ?)
> or
> - use environment variables that hints/ queries

I don't think new features would be required.

There already are -D options for 64-bit:

If you run perldoc on blead's pod/perlapi.pod, you'll find explanations 
for these and lots of other symbols that can be used in C conditional 

I would think that if the perl was compiled under z/OS running ASCII it 
would create an ASCII binary; similarly for EBCDIC, so again, no feature 
would be required.

> In either case, I am expecting I would update the hints/ to be 
> able to support these 2 new features. There are macros that get defined 
> by both ASCII compilation and 64-bit compilation that can be queried in 
> the code as required?

One of the symbols #defined is EBCDIC.  There are other symbols that 
yield the size of integers and pointers.

But my guess is that this is a lot easier than you are anticipating.  I 
suspect that all that is necessary is to remove any assumptions in the 
code that z/OS is always EBCDIC.  Everything else should fall out 

I have worked to remove most of the #ifdef EBCDIC lines in the code, 
with a few base macros hiding the differences from higher levels.  Very 
little remains that actually needs to know the distinctions.

There are tests we skip on z/OS mainly because we don't have the 
expertise with the OS to figure things out.  I suspect you bring that 
expertise to the project.  Some of those tests may wrongly be skipped 
based on it being EBCDIC rather than the OS.
> My other starter question:
> - presumably, it is better to have smaller commits rather than some big 
> commits. Would it be reasonable to start with a first commit to try to 
> get hints/ 'close', even if the ASCII and 64-bit paths aren't 
> complete yet, or is the preference to get it all working and then 
> check-in things? Even to get the 31-bit EBCDIC static path working, I 
> expect I will need to make changes to hints/ (and perhaps other 
> code too)

To paraphrase Huxley, "Small commits good; Big commits bad".
We can always squash commits.

blead should already compile and run on z/OS EBCDIC, statically, 
dynamically, 32 and 64 bit.  It's been a couple of months since I 
checked, though.

> Finally:
> - is email the way you want to proceed or is there another method you 
> would prefer?

Email is good.  We may want to do these details privately to avoid noise 
that isn't really relevant to most people's interests.  If anyone 
objects to this, speak up (or email up) now.

But to get you faster responses, I suggest irc.  I suggest we start with #p5p.  If this leads to too much traffic we could create a 
new channel.

Also, getting started we may want to schedule a zoom or phone call.
> thanks, mike fulton

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About