Discussion:
[H390-MVS] Unysis conversion
João Reginato jb.reginato@gmail.com [H390-MVS]
2018-02-07 14:53:12 UTC
Permalink
Hi guys



Does anybody know any kind of sw to convert MVS assembler programs to Unysis
world?

Any tip welcome



TIA

João
kerravon86@yahoo.com.au [H390-MVS]
2018-02-07 14:15:14 UTC
Permalink
Post by João Reginato ***@gmail.com [H390-MVS]
Does anybody know any kind of sw to convert
MVS assembler programs to Unysis world?
Any tip welcome
Well some people seem to believe that MVS
assembler is a realistic alternative to writing
in C. Now would be a good time for them to
explain how to compile MVS assembly into
Unisys machine code, whatever format that is.

One place that was cited was z390.org, but
I've never used that personally and don't know
if it supports Unisys.

Another thing I would ask is just how time
critical these assembler programs are. Is there
a reason why they can't be run on Hercules,
possibly running MVS/380?

You can debate this in hercules-os380 if it is
off-topic here.

BFN. Paul.
João Reginato jb.reginato@gmail.com [H390-MVS]
2018-02-07 15:31:00 UTC
Permalink
Thanks Paul



In fact I’d like to run my MVS sw in an Unisys real environment





De: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 11:15
Para: H390-***@yahoogroups.com
Assunto: [H390-MVS] Re: Unysis conversion
Post by João Reginato ***@gmail.com [H390-MVS]
Does anybody know any kind of sw to convert
MVS assembler programs to Unysis world?
Any tip welcome
Well some people seem to believe that MVS
assembler is a realistic alternative to writing
in C. Now would be a good time for them to
explain how to compile MVS assembly into
Unisys machine code, whatever format that is.

One place that was cited was z390.org, but
I've never used that personally and don't know
if it supports Unisys.

Another thing I would ask is just how time
critical these assembler programs are. Is there
a reason why they can't be run on Hercules,
possibly running MVS/380?

You can debate this in hercules-os380 if it is
off-topic here.

BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-07 15:07:51 UTC
Permalink
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?

Is the code time-critical that you can't afford
the Hercules overhead?

Is the MVS code batch or TSO?

If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?

Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.

BFN. Paul.
João Reginato jb.reginato@gmail.com [H390-MVS]
2018-02-07 17:06:29 UTC
Permalink
Very interesting,

however the user doesn’t want to run Hercules in his production machine.

ThatÂŽs why I have to convert the programs





De: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 12:08
Para: H390-***@yahoogroups.com
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?

Is the code time-critical that you can't afford
the Hercules overhead?

Is the MVS code batch or TSO?

If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?

Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.

BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-07 16:29:51 UTC
Permalink
Ask the user why running compiled S/370 code
on the production machine is OK, but running
compiled C code on the production machine is
not OK.

Source code for both is probably available
(definitely available for Hercules) so maybe
he doesn't understand what Hercules is.
Does he understand that he doesn't need
to actually operate Hercules, it can all be
set up to start and terminate automatically?
Unless there's some sort of Hercules bug,
anyway (occasionally a batch run will fail
for me).

Also, Hercules can probably be compiled
into Unisys assembler which is presumably
allowed.

BFN. Paul.




---In H390-***@yahoogroups.com, <***@...> wrote :

Very interesting,
however the user doesn’t want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs


De: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 12:08
Para: H390-***@yahoogroups.com
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?

Is the code time-critical that you can't afford
the Hercules overhead?

Is the MVS code batch or TSO?

If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?

Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.

BFN. Paul.
João Reginato jb.reginato@gmail.com [H390-MVS]
2018-02-07 17:47:11 UTC
Permalink
Another interesting point of view.

But the sw will be up and running 24 hours/day





De: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:30
Para: H390-***@yahoogroups.com
Assunto: Re: RES: RES: [H390-MVS] Re: Unysis conversion





Ask the user why running compiled S/370 code
on the production machine is OK, but running
compiled C code on the production machine is
not OK.

Source code for both is probably available
(definitely available for Hercules) so maybe
he doesn't understand what Hercules is.
Does he understand that he doesn't need
to actually operate Hercules, it can all be
set up to start and terminate automatically?
Unless there's some sort of Hercules bug,
anyway (occasionally a batch run will fail
for me).

Also, Hercules can probably be compiled
into Unisys assembler which is presumably
allowed.

BFN. Paul.

---In H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> , <***@... <mailto:***@...> > wrote :

Very interesting,
however the user doesn’t want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs


De: H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> [mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 12:08
Para: H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com>
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?

Is the code time-critical that you can't afford
the Hercules overhead?

Is the MVS code batch or TSO?

If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?

Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.

BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-07 17:11:52 UTC
Permalink
(possible double-post due to Yahoo)


Can you tell me the nature of the S/370 code that
is supposedly running 24 hours/day? It's clearly
not a batch job if that's the case. Is it a CICS
application? Written in S/370 assembler???

If it's part of an application suite, you can just
execute a script whenever you need this
functionality. The script will start MVS and
run your S/370 code and produce an output
file. Note that you can execute an IEFBR14
in about 5 seconds, ie that's how long it
takes to IPL MVS on a PC.

How many separate S/370 programs and
source files are involved?

If it's an S/370 routine to calculate "pi" or
something, then Hercules isn't of much use
to you. Although even then, it's still not out
of the question as you could always compile
your main (C?) application into S/370 instead of
Unisys to provide a standalone load module.
Sure, it won't be as fast as having the application
written all in C so that you can produce Unisys
code, but it depends on your exact application
whether this is an issue or not.

BFN. Paul.




---In H390-***@yahoogroups.com, <***@...> wrote :

Another interesting point of view.
But the sw will be up and running 24 hours/day


De: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:30
Para: H390-***@yahoogroups.com
Assunto: Re: RES: RES: [H390-MVS] Re: Unysis conversion




Ask the user why running compiled S/370 code
on the production machine is OK, but running
compiled C code on the production machine is
not OK.

Source code for both is probably available
(definitely available for Hercules) so maybe
he doesn't understand what Hercules is.
Does he understand that he doesn't need
to actually operate Hercules, it can all be
set up to start and terminate automatically?
Unless there's some sort of Hercules bug,
anyway (occasionally a batch run will fail
for me).

Also, Hercules can probably be compiled
into Unisys assembler which is presumably
allowed.

BFN. Paul.

---In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com, <***@... mailto:***@...> wrote :

Very interesting,
however the user doesn’t want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs


De: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 12:08
Para: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?

Is the code time-critical that you can't afford
the Hercules overhead?

Is the MVS code batch or TSO?

If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?

Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.

BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-07 16:58:26 UTC
Permalink
Can you tell me the nature of the S/370 code that
is supposedly running 24 hours/day? It's clearly
not a batch job if that's the case. Is it a CICS
application? Written in S/370 assembler???

If it's part of an application suite, you can just
execute a script whenever you need this
functionality. The script will start MVS and
run your S/370 code and produce an output
file. Note that you can execute an IEFBR14
in about 5 seconds, ie that's how long it
takes to IPL MVS on a PC.

How many separate S/370 programs and
source files are involved?

If it's an S/370 routine to calculate "pi" or
something, then Hercules isn't of much use
to you. Although even then, it's still not out
of the question as you could always compile
your main (C?) application into S/370 instead of
Unisys to provide a standalone load module.
Sure, it won't be as fast as having the application
written all in C so that you can produce Unisys
code, but it depends on your exact application
whether this is an issue or not.

BFN. Paul.




---In H390-***@yahoogroups.com, <***@...> wrote :

Another interesting point of view.
But the sw will be up and running 24 hours/day


De: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:30
Para: H390-***@yahoogroups.com
Assunto: Re: RES: RES: [H390-MVS] Re: Unysis conversion




Ask the user why running compiled S/370 code
on the production machine is OK, but running
compiled C code on the production machine is
not OK.

Source code for both is probably available
(definitely available for Hercules) so maybe
he doesn't understand what Hercules is.
Does he understand that he doesn't need
to actually operate Hercules, it can all be
set up to start and terminate automatically?
Unless there's some sort of Hercules bug,
anyway (occasionally a batch run will fail
for me).

Also, Hercules can probably be compiled
into Unisys assembler which is presumably
allowed.

BFN. Paul.

---In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com, <***@... mailto:***@...> wrote :

Very interesting,
however the user doesn’t want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs


De: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 12:08
Para: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?

Is the code time-critical that you can't afford
the Hercules overhead?

Is the MVS code batch or TSO?

If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?

Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.

BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-07 18:00:05 UTC
Permalink
I have thought of one more option, which is in
embryonic form over at hercules-os380.

If you wish to run some complex S/370 assembler
routine from a C program on Unisys, what you can
potentially do is have a mongrel load module.

You compile your Unisys C code into Unisys
machine code and produce something that is
similar to a Unisys executable, except when it
comes time to calculate pi or whatever your
S/370 code does, your load module instead
does a callback to Hercules, and Hercules
executes the S/370 routine, and when complete,
control returns to your C program.

And for my own purposes I've just thought of
another option - Hercules could potentially be
embedded inside FreeBSD, potentially
simplifying the callback mechanism.

BFN. Paul.
João Reginato jb.reginato@gmail.com [H390-MVS]
2018-02-07 19:36:39 UTC
Permalink
The sw to run is like an improved FTP server and must be available to send/receive files anytime, among other functionalities







De: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:58
Para: H390-***@yahoogroups.com
Assunto: Re: RES: RES: RES: [H390-MVS] Re: Unysis conversion





Can you tell me the nature of the S/370 code that
is supposedly running 24 hours/day? It's clearly
not a batch job if that's the case. Is it a CICS
application? Written in S/370 assembler???

If it's part of an application suite, you can just
execute a script whenever you need this
functionality. The script will start MVS and
run your S/370 code and produce an output
file. Note that you can execute an IEFBR14
in about 5 seconds, ie that's how long it
takes to IPL MVS on a PC.

How many separate S/370 programs and
source files are involved?

If it's an S/370 routine to calculate "pi" or
something, then Hercules isn't of much use
to you. Although even then, it's still not out
of the question as you could always compile
your main (C?) application into S/370 instead of
Unisys to provide a standalone load module.
Sure, it won't be as fast as having the application
written all in C so that you can produce Unisys
code, but it depends on your exact application
whether this is an issue or not.

BFN. Paul.

---In H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> , <***@... <mailto:***@...> > wrote :

Another interesting point of view.
But the sw will be up and running 24 hours/day


De: H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> [mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:30
Para: H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com>
Assunto: Re: RES: RES: [H390-MVS] Re: Unysis conversion

Ask the user why running compiled S/370 code
on the production machine is OK, but running
compiled C code on the production machine is
not OK.

Source code for both is probably available
(definitely available for Hercules) so maybe
he doesn't understand what Hercules is.
Does he understand that he doesn't need
to actually operate Hercules, it can all be
set up to start and terminate automatically?
Unless there's some sort of Hercules bug,
anyway (occasionally a batch run will fail
for me).

Also, Hercules can probably be compiled
into Unisys assembler which is presumably
allowed.

BFN. Paul.

---In H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> mailto:H390-***@yahoogroups.com, <***@... mailto:***@... <mailto:***@...%20mailto:***@...> > wrote :

Very interesting,
however the user doesn’t want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs

De: H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> mailto:H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com%20mailto:H390-***@yahoogroups.com> ]
Enviada em: quarta-feira, 7 de fevereiro de 2018 12:08
Para: H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> mailto:H390-***@yahoogroups.com
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?

Is the code time-critical that you can't afford
the Hercules overhead?

Is the MVS code batch or TSO?

If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?

Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.

BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-07 18:52:22 UTC
Permalink
And what does the S/370 assembler component of
that do?

If the S/370 assembler currently does an OPEN of
DDNAME SYSUT1, and checks the DCB information
to see if it is F/V/U and then does various processing
based on that, how were you hoping that a S/370
translator would translate that code to be suitable
for Unisys?

And how many lines of S/370 assembler are we
talking about? It may be simpler to write replacement
code in C, which is possibly what the original
S/370 assembler should have been written in in the
first place, to solve this exact problem you are facing.
You're in with a shot at porting C code, but there's
a dearth of options when it comes to 370 assembler.

BFN. Paul.





---In H390-***@yahoogroups.com, <***@...> wrote :

The sw to run is like an improved FTP server and must be available to send/receive files anytime, among other functionalities



De: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:58
Para: H390-***@yahoogroups.com
Assunto: Re: RES: RES: RES: [H390-MVS] Re: Unysis conversion




Can you tell me the nature of the S/370 code that
is supposedly running 24 hours/day? It's clearly
not a batch job if that's the case. Is it a CICS
application? Written in S/370 assembler???

If it's part of an application suite, you can just
execute a script whenever you need this
functionality. The script will start MVS and
run your S/370 code and produce an output
file. Note that you can execute an IEFBR14
in about 5 seconds, ie that's how long it
takes to IPL MVS on a PC.

How many separate S/370 programs and
source files are involved?

If it's an S/370 routine to calculate "pi" or
something, then Hercules isn't of much use
to you. Although even then, it's still not out
of the question as you could always compile
your main (C?) application into S/370 instead of
Unisys to provide a standalone load module.
Sure, it won't be as fast as having the application
written all in C so that you can produce Unisys
code, but it depends on your exact application
whether this is an issue or not.

BFN. Paul.

---In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com, <***@... mailto:***@...> wrote :

Another interesting point of view.
But the sw will be up and running 24 hours/day


De: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:30
Para: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com
Assunto: Re: RES: RES: [H390-MVS] Re: Unysis conversion

Ask the user why running compiled S/370 code
on the production machine is OK, but running
compiled C code on the production machine is
not OK.

Source code for both is probably available
(definitely available for Hercules) so maybe
he doesn't understand what Hercules is.
Does he understand that he doesn't need
to actually operate Hercules, it can all be
set up to start and terminate automatically?
Unless there's some sort of Hercules bug,
anyway (occasionally a batch run will fail
for me).

Also, Hercules can probably be compiled
into Unisys assembler which is presumably
allowed.

BFN. Paul.

---In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com, <***@... mailto:***@... mailto:***@...%20mailto:***@...> wrote :

Very interesting,
however the user doesn’t want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs

De: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com%20mailto:H390-***@yahoogroups.com]
Enviada em: quarta-feira, 7 de fevereiro de 2018 12:08
Para: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?

Is the code time-critical that you can't afford
the Hercules overhead?

Is the MVS code batch or TSO?

If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?

Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.

BFN. Paul.
'Dave Wade' dave.g4ugm@gmail.com [H390-MVS]
2018-02-07 19:26:40 UTC
Permalink
Paul,
The original writer probably didn't have "C" available. I maintained code in FORTRAN and Assembler that did a similar thing over x.25 networks because many Universities did not have a Mainframe "C" compiler.
I bet its all in assembler. If it uses a TCP/IP network then which tcp/ip interface does it use (I think there are at least three).
What security interfaces does it use? Does it interface to RACF? Sounds really nasty...
Whats at the other end?
Dave
-----Original Message-----
Sent: 07 February 2018 18:52
Subject: Re: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion
And what does the S/370 assembler component of that do?
If the S/370 assembler currently does an OPEN of DDNAME SYSUT1, and
checks the DCB information to see if it is F/V/U and then does various
processing based on that, how were you hoping that a S/370 translator would
translate that code to be suitable for Unisys?
And how many lines of S/370 assembler are we talking about? It may be
simpler to write replacement code in C, which is possibly what the original
S/370 assembler should have been written in in the first place, to solve this
exact problem you are facing.
You're in with a shot at porting C code, but there's a dearth of options when
it comes to 370 assembler.
BFN. Paul.
The sw to run is like an improved FTP server and must be available to
send/receive files anytime, among other functionalities
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:58
Assunto: Re: RES: RES: RES: [H390-MVS] Re: Unysis conversion
Can you tell me the nature of the S/370 code that
is supposedly running 24 hours/day? It's clearly
not a batch job if that's the case. Is it a CICS
application? Written in S/370 assembler???
If it's part of an application suite, you can just
execute a script whenever you need this
functionality. The script will start MVS and
run your S/370 code and produce an output
file. Note that you can execute an IEFBR14
in about 5 seconds, ie that's how long it
takes to IPL MVS on a PC.
How many separate S/370 programs and
source files are involved?
If it's an S/370 routine to calculate "pi" or
something, then Hercules isn't of much use
to you. Although even then, it's still not out
of the question as you could always compile
your main (C?) application into S/370 instead of
Unisys to provide a standalone load module.
Sure, it won't be as fast as having the application
written all in C so that you can produce Unisys
code, but it depends on your exact application
whether this is an issue or not.
BFN. Paul.
Another interesting point of view.
But the sw will be up and running 24 hours/day
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:30
Assunto: Re: RES: RES: [H390-MVS] Re: Unysis conversion
Ask the user why running compiled S/370 code
on the production machine is OK, but running
compiled C code on the production machine is
not OK.
Source code for both is probably available
(definitely available for Hercules) so maybe
he doesn't understand what Hercules is.
Does he understand that he doesn't need
to actually operate Hercules, it can all be
set up to start and terminate automatically?
Unless there's some sort of Hercules bug,
anyway (occasionally a batch run will fail
for me).
Also, Hercules can probably be compiled
into Unisys assembler which is presumably
allowed.
BFN. Paul.
Very interesting,
however the user doesn’t want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs
Enviada em: quarta-feira, 7 de fevereiro de 2018 12:08
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?
Is the code time-critical that you can't afford
the Hercules overhead?
Is the MVS code batch or TSO?
If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?
Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links
Joe Monk joemonk64@gmail.com [H390-MVS]
2018-02-07 22:07:40 UTC
Permalink
Oi Joao, tudo bem?

Eu tem duvidas sobre seu correio... (I have some questions about your
email)...

1. Como esta sistema de operação em UNISYS? (What is the Unisys OS?)
2. Como esta modelo de computadora? (What is the model of the Unisys?)

Eu acho o aplicação e muito legal...

Joe
Post by 'Dave Wade' ***@gmail.com [H390-MVS]
Paul,
The original writer probably didn't have "C" available. I maintained code
in FORTRAN and Assembler that did a similar thing over x.25 networks
because many Universities did not have a Mainframe "C" compiler.
I bet its all in assembler. If it uses a TCP/IP network then which tcp/ip
interface does it use (I think there are at least three).
What security interfaces does it use? Does it interface to RACF? Sounds really nasty...
Whats at the other end?
Dave
-----Original Message-----
Sent: 07 February 2018 18:52
Subject: Re: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion
And what does the S/370 assembler component of that do?
If the S/370 assembler currently does an OPEN of DDNAME SYSUT1, and
checks the DCB information to see if it is F/V/U and then does various
processing based on that, how were you hoping that a S/370 translator
would
translate that code to be suitable for Unisys?
And how many lines of S/370 assembler are we talking about? It may be
simpler to write replacement code in C, which is possibly what the
original
S/370 assembler should have been written in in the first place, to solve
this
exact problem you are facing.
You're in with a shot at porting C code, but there's a dearth of options
when
it comes to 370 assembler.
BFN. Paul.
The sw to run is like an improved FTP server and must be available to
send/receive files anytime, among other functionalities
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:58
Assunto: Re: RES: RES: RES: [H390-MVS] Re: Unysis conversion
Can you tell me the nature of the S/370 code that
is supposedly running 24 hours/day? It's clearly
not a batch job if that's the case. Is it a CICS
application? Written in S/370 assembler???
If it's part of an application suite, you can just
execute a script whenever you need this
functionality. The script will start MVS and
run your S/370 code and produce an output
file. Note that you can execute an IEFBR14
in about 5 seconds, ie that's how long it
takes to IPL MVS on a PC.
How many separate S/370 programs and
source files are involved?
If it's an S/370 routine to calculate "pi" or
something, then Hercules isn't of much use
to you. Although even then, it's still not out
of the question as you could always compile
your main (C?) application into S/370 instead of
Unisys to provide a standalone load module.
Sure, it won't be as fast as having the application
written all in C so that you can produce Unisys
code, but it depends on your exact application
whether this is an issue or not.
BFN. Paul.
Another interesting point of view.
But the sw will be up and running 24 hours/day
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:30
Assunto: Re: RES: RES: [H390-MVS] Re: Unysis conversion
Ask the user why running compiled S/370 code
on the production machine is OK, but running
compiled C code on the production machine is
not OK.
Source code for both is probably available
(definitely available for Hercules) so maybe
he doesn't understand what Hercules is.
Does he understand that he doesn't need
to actually operate Hercules, it can all be
set up to start and terminate automatically?
Unless there's some sort of Hercules bug,
anyway (occasionally a batch run will fail
for me).
Also, Hercules can probably be compiled
into Unisys assembler which is presumably
allowed.
BFN. Paul.
Very interesting,
however the user doesn’t want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs
Enviada em: quarta-feira, 7 de fevereiro de 2018 12:08
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion
....%2
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?
Is the code time-critical that you can't afford
the Hercules overhead?
Is the MVS code batch or TSO?
If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?
Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links
kerravon86@yahoo.com.au [H390-MVS]
2018-02-08 01:10:43 UTC
Permalink
Hi Dave.

What year did you write in Fortran because of the
unavailability of C?

I wonder what things would have looked like if
GCC had been ported earlier.

BFN. Paul.




---In H390-***@yahoogroups.com, <***@...> wrote :

Paul,
The original writer probably didn't have "C" available. I maintained code in FORTRAN and Assembler that did a similar thing over x.25 networks because many Universities did not have a Mainframe "C" compiler.
I bet its all in assembler. If it uses a TCP/IP network then which tcp/ip interface does it use (I think there are at least three).
What security interfaces does it use? Does it interface to RACF? Sounds really nasty...
Whats at the other end?
Dave
-----Original Message-----
Sent: 07 February 2018 18:52
Subject: Re: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion
And what does the S/370 assembler component of that do?
If the S/370 assembler currently does an OPEN of DDNAME SYSUT1, and
checks the DCB information to see if it is F/V/U and then does various
processing based on that, how were you hoping that a S/370 translator would
translate that code to be suitable for Unisys?
And how many lines of S/370 assembler are we talking about? It may be
simpler to write replacement code in C, which is possibly what the original
S/370 assembler should have been written in in the first place, to solve this
exact problem you are facing.
You're in with a shot at porting C code, but there's a dearth of options when
it comes to 370 assembler.
BFN. Paul.
The sw to run is like an improved FTP server and must be available to
send/receive files anytime, among other functionalities
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:58
Assunto: Re: RES: RES: RES: [H390-MVS] Re: Unysis conversion
Can you tell me the nature of the S/370 code that
is supposedly running 24 hours/day? It's clearly
not a batch job if that's the case. Is it a CICS
application? Written in S/370 assembler???
If it's part of an application suite, you can just
execute a script whenever you need this
functionality. The script will start MVS and
run your S/370 code and produce an output
file. Note that you can execute an IEFBR14
in about 5 seconds, ie that's how long it
takes to IPL MVS on a PC.
How many separate S/370 programs and
source files are involved?
If it's an S/370 routine to calculate "pi" or
something, then Hercules isn't of much use
to you. Although even then, it's still not out
of the question as you could always compile
your main (C?) application into S/370 instead of
Unisys to provide a standalone load module.
Sure, it won't be as fast as having the application
written all in C so that you can produce Unisys
code, but it depends on your exact application
whether this is an issue or not.
BFN. Paul.
Another interesting point of view.
But the sw will be up and running 24 hours/day
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:30
Assunto: Re: RES: RES: [H390-MVS] Re: Unysis conversion
Ask the user why running compiled S/370 code
on the production machine is OK, but running
compiled C code on the production machine is
not OK.
Source code for both is probably available
(definitely available for Hercules) so maybe
he doesn't understand what Hercules is.
Does he understand that he doesn't need
to actually operate Hercules, it can all be
set up to start and terminate automatically?
Unless there's some sort of Hercules bug,
anyway (occasionally a batch run will fail
for me).
Also, Hercules can probably be compiled
into Unisys assembler which is presumably
allowed.
BFN. Paul.
Very interesting,
however the user doesn’t want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs
Enviada em: quarta-feira, 7 de fevereiro de 2018 12:08
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?
Is the code time-critical that you can't afford
the Hercules overhead?
Is the MVS code batch or TSO?
If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?
Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links
Joe Monk joemonk64@gmail.com [H390-MVS]
2018-02-08 01:51:59 UTC
Permalink
Paul,

There are still mainframe shops today that dont have a C compiler.

Joe
Post by ***@yahoo.com.au [H390-MVS]
Hi Dave.
What year did you write in Fortran because of the
unavailability of C?
I wonder what things would have looked like if
GCC had been ported earlier.
BFN. Paul.
Paul,
The original writer probably didn't have "C" available. I maintained code
in FORTRAN and Assembler that did a similar thing over x.25 networks
because many Universities did not have a Mainframe "C" compiler.
I bet its all in assembler. If it uses a TCP/IP network then which tcp/ip
interface does it use (I think there are at least three).
What security interfaces does it use? Does it interface to RACF? Sounds really nasty...
Whats at the other end?
Dave
-----Original Message-----
Sent: 07 February 2018 18:52
Subject: Re: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion
And what does the S/370 assembler component of that do?
If the S/370 assembler currently does an OPEN of DDNAME SYSUT1, and
checks the DCB information to see if it is F/V/U and then does various
processing based on that, how were you hoping that a S/370 translator
would
translate that code to be suitable for Unisys?
And how many lines of S/370 assembler are we talking about? It may be
simpler to write replacement code in C, which is possibly what the
original
S/370 assembler should have been written in in the first place, to solve
this
exact problem you are facing.
You're in with a shot at porting C code, but there's a dearth of options
when
it comes to 370 assembler.
BFN. Paul.
The sw to run is like an improved FTP server and must be available to
send/receive files anytime, among other functionalities
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:58
Assunto: Re: RES: RES: RES: [H390-MVS] Re: Unysis conversion
Can you tell me the nature of the S/370 code that
is supposedly running 24 hours/day? It's clearly
not a batch job if that's the case. Is it a CICS
application? Written in S/370 assembler???
If it's part of an application suite, you can just
execute a script whenever you need this
functionality. The script will start MVS and
run your S/370 code and produce an output
file. Note that you can execute an IEFBR14
in about 5 seconds, ie that's how long it
takes to IPL MVS on a PC.
How many separate S/370 programs and
source files are involved?
If it's an S/370 routine to calculate "pi" or
something, then Hercules isn't of much use
to you. Although even then, it's still not out
of the question as you could always compile
your main (C?) application into S/370 instead of
Unisys to provide a standalone load module.
Sure, it won't be as fast as having the application
written all in C so that you can produce Unisys
code, but it depends on your exact application
whether this is an issue or not.
BFN. Paul.
Another interesting point of view.
But the sw will be up and running 24 hours/day
H390-
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:30
Assunto: Re: RES: RES: [H390-MVS] Re: Unysis conversion
Ask the user why running compiled S/370 code
on the production machine is OK, but running
compiled C code on the production machine is
not OK.
Source code for both is probably available
(definitely available for Hercules) so maybe
he doesn't understand what Hercules is.
Does he understand that he doesn't need
to actually operate Hercules, it can all be
set up to start and terminate automatically?
Unless there's some sort of Hercules bug,
anyway (occasionally a batch run will fail
for me).
Also, Hercules can probably be compiled
into Unisys assembler which is presumably
allowed.
BFN. Paul.
Very interesting,
however the user doesn’t want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs
%20mailto:H390-
Enviada em: quarta-feira, 7 de fevereiro de 2018 12:08
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion
....%2
Post by João Reginato ***@gmail.com [H390-MVS]
In fact I’d like to run my MVS sw in an Unisys real environment
Running Hercules under Unisys *is* a real
Unisys environment, isn't it?
Is the code time-critical that you can't afford
the Hercules overhead?
Is the MVS code batch or TSO?
If it is batch, are you aware that you can
automatically start Hercules, run an MVS
job, transfer the output file, all automatically
using the "runmvs" script that is available
as part of the MVS/380 project?
Depending on your requirements there is
also Jason Winter's code to provide host
file access that may enter the discussion.
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links
Gregg Levine gregg.drwho8@gmail.com [H390-MVS]
2018-02-08 02:07:23 UTC
Permalink
Hello!
I agree. It shows up sometimes on the IBMVM list, and oddly enough
does not show up on the Linux-390 list. For the main stream (or is
that mainframe) operating systems, remember you get the base system as
part of the order. Certain items are a chargable product, and that's
the C compiler.

Now let's move on to something else.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."
Post by Joe Monk ***@gmail.com [H390-MVS]
Paul,
There are still mainframe shops today that dont have a C compiler.
Joe
Post by ***@yahoo.com.au [H390-MVS]
Hi Dave.
What year did you write in Fortran because of the
unavailability of C?
I wonder what things would have looked like if
GCC had been ported earlier.
BFN. Paul.
Paul,
The original writer probably didn't have "C" available. I maintained code
in FORTRAN and Assembler that did a similar thing over x.25 networks because
many Universities did not have a Mainframe "C" compiler.
I bet its all in assembler. If it uses a TCP/IP network then which tcp/ip
interface does it use (I think there are at least three).
What security interfaces does it use? Does it interface to RACF? Sounds really nasty...
Whats at the other end?
Dave
-----Original Message-----
And what does the S/370 assembler component of that do?
If the S/370 assembler currently does an OPEN of DDNAME SYSUT1, and
checks the DCB information to see if it is F/V/U and then does various
processing based on that, how were you hoping that a S/370 translator would
translate that code to be suitable for Unisys?
And how many lines of S/370 assembler are we talking about? It may be
simpler to write replacement code in C, which is possibly what the original
S/370 assembler should have been written in in the first place, to solve this
exact problem you are facing.
You're in with a shot at porting C code, but there's a dearth of options when
it comes to 370 assembler.
BFN. Paul.
The sw to run is like an improved FTP server and must be available to
send/receive files anytime, among other functionalities
Can you tell me the nature of the S/370 code that
is supposedly running 24 hours/day? It's clearly
not a batch job if that's the case. Is it a CICS
application? Written in S/370 assembler???
If it's part of an application suite, you can just
execute a script whenever you need this
functionality. The script will start MVS and
run your S/370 code and produce an output
file. Note that you can execute an IEFBR14
in about 5 seconds, ie that's how long it
takes to IPL MVS on a PC.
How many separate S/370 programs and
source files are involved?
If it's an S/370 routine to calculate "pi" or
something, then Hercules isn't of much use
to you. Although even then, it's still not out
of the question as you could always compile
your main (C?) application into S/370 instead of
Unisys to provide a standalone load module.
Sure, it won't be as fast as having the application
written all in C so that you can produce Unisys
code, but it depends on your exact application
whether this is an issue or not.
BFN. Paul.
Another interesting point of view.
But the sw will be up and running 24 hours/day
Ask the user why running compiled S/370 code
on the production machine is OK, but running
compiled C code on the production machine is
not OK.
Source code for both is probably available
(definitely available for Hercules) so maybe
he doesn't understand what Hercules is.
Does he understand that he doesn't need
to actually operate Hercules, it can all be
set up to start and terminate automatically?
Unless there's some sort of Hercules bug,
anyway (occasionally a batch run will fail
for me).
Also, Hercules can probably be compiled
into Unisys assembler which is presumably
allowed.
BFN. Paul.
Gerhard Postpischil gerhardp@charter.net [H390-MVS]
2018-02-08 02:19:20 UTC
Permalink
Post by ***@yahoo.com.au [H390-MVS]
What year did you write in Fortran because of the
unavailability of C?
I don't now about Dave, but I started using
ForTran in 1963. The available option on our 709/7094 machines were
ForTran and FAP (ForTran Aseemler Program). About a year or so later we
got the $IBSYS system with ForTran and MAP. No C, n GCC, and we were all
better for it.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com
kerravon86@yahoo.com.au [H390-MVS]
2018-02-08 02:59:45 UTC
Permalink
Post by Gerhard Postpischil ***@charter.net [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
What year did you write in Fortran because of the
unavailability of C?
I don't now about Dave, but I started using
ForTran in 1963. The available option on our 709/7094 machines were
ForTran and FAP (ForTran Aseemler Program). About a year or so later we
got the $IBSYS system with ForTran and MAP. No C, n GCC, and we were all
better for it.
You're not better for it when it's time to port
the code to Unisys.

Now is your big chance to show that 370
assembler is just as portable as C.

@joe - shops that do not have a C compiler
in 2017 are doing so by choice, not because
they can't cost-justify buying a C compiler.

BFN. Paul.
'Bill Turner, WB4ALM' wb4alm@arrl.net [H390-MVS]
2018-02-08 05:13:38 UTC
Permalink
When 90% of your production programs are written in COBOL, and when you
have to consider the cost of 100's of copies of leased software (one for
each mainframe image) you better beleive you CAN NOT cost justify buying
new compiliers for languages that aren't going to be used very often.

Sure wish you would get your head out of the sand with this belief that
--ONLY-- "C" should be used for anything...

/s/ Bill Turner, wb4alm
Post by ***@yahoo.com.au [H390-MVS]
@joe - shops that do not have a C compiler
in 2017 are doing so by choice, not because
they can't cost-justify buying a C compiler.
BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-08 05:45:32 UTC
Permalink
C is available either as standard, or for free,
on all commercially-used platforms, as far
as I know.

And I sure wish you would understand that
I'm advocating using C for anything on MVS
that you would otherwise write in 370
assembler, if you may ever be in a situation
where you need to port to Unisys. As is the
case now. Write it once. Write it in C.

BFN. Paul.




---In H390-***@yahoogroups.com, <***@...> wrote :

When 90% of your production programs are written in COBOL, and when you have to consider the cost of 100's of copies of leased software (one for each mainframe image) you better beleive you CAN NOT cost justify buying new compiliers for languages that aren't going to be used very often.

Sure wish you would get your head out of the sand with this belief that --ONLY-- "C" should be used for anything...

/s/ Bill Turner, wb4alm


On 02/07/2018 09:59 PM, ***@... mailto:***@... [H390-MVS] wrote:



@joe - shops that do not have a C compiler
in 2017 are doing so by choice, not because
they can't cost-justify buying a C compiler.

BFN. Paul.
Joe Monk joemonk64@gmail.com [H390-MVS]
2018-02-08 12:04:52 UTC
Permalink
"C is available either as standard, or for free,
on all commercially-used platforms, as far
as I know."

Paul,

IBM charges $$$ for the C language on mainframes. It is not FREE, nor is it
standard.

Joe
Post by ***@yahoo.com.au [H390-MVS]
C is available either as standard, or for free,
on all commercially-used platforms, as far
as I know.
And I sure wish you would understand that
I'm advocating using C for anything on MVS
that you would otherwise write in 370
assembler, if you may ever be in a situation
where you need to port to Unisys. As is the
case now. Write it once. Write it in C.
BFN. Paul.
When 90% of your production programs are written in COBOL, and when you
have to consider the cost of 100's of copies of leased software (one for
each mainframe image) you better beleive you CAN NOT cost justify buying
new compiliers for languages that aren't going to be used very often.
Sure wish you would get your head out of the sand with this belief that
--ONLY-- "C" should be used for anything...
/s/ Bill Turner, wb4alm
@joe - shops that do not have a C compiler
in 2017 are doing so by choice, not because
they can't cost-justify buying a C compiler.
BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-08 14:13:00 UTC
Permalink
Post by Joe Monk ***@gmail.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
C is available either as standard, or for free,
on all commercially-used platforms, as far
as I know.
IBM charges $$$ for the C language on mainframes.
It is not FREE, nor is it standard.
GCCMVS is free on all commercially-used
mainframe environments, even z/VSE.

z/VSE was literally the last commercially-used
programming environment that I am aware of
that didn't have either a free or standard C
compiler available. It is for this reason that I
consider C to be the universal language for
computers.

BFN. Paul.
Dave Wade dave.g4ugm@gmail.com [H390-MVS]
2018-02-08 11:51:19 UTC
Permalink
Post by ***@yahoo.com.au [H390-MVS]
Post by Gerhard Postpischil ***@charter.net [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
What year did you write in Fortran because of the
unavailability of C?
I don't now about Dave, but I started using
ForTran in 1963. The available option on our 709/7094 machines were
ForTran and FAP (ForTran Aseemler Program). About a year or so later we
got the $IBSYS system with ForTran and MAP. No C, n GCC, and we were all
better for it.
You're not better for it when it's time to port
the code to Unisys.
Now is your big chance to show that 370
assembler is just as portable as C.
@joe - shops that do not have a C compiler
in 2017 are doing so by choice, not because
they can't cost-justify buying a C compiler.
BFN. Paul.
I can easily justify not installing a C compiler on cost, even if the
compiler is free. Any stuff written in Fortran will still compile on a
modern system.


Dave
ggs@shiresoft.com [H390-MVS]
2018-02-08 17:21:42 UTC
Permalink
For some background I've been writing in C since 1977 (Unix v6 days).

The C language has changed *a lot* over time (v6 -> v7, k&r, ansi, c-89, c-99, etc). Not to mention the various sub-standards (such as MISRA which I'm currently dealing with).

The issue with C is that *a lot* is left up to the compiler. For example, what is the size of an int? Order of bits in a bit-field is completely up to the compiler. Frankly, the language definition itself has lots of issues that simple typographical mistakes can lead to difficult to diagnose bugs (e.g. mis-typing = for == in a comparison). That's even leaving off the potential issue of endianness.


Anyone who's actually had to do cross platform compatibility (or porting) will quickly realize that C is *not* portable. Trying to write portable C is *hard* and even those who've been doing it for a long time (in my case decades) still get "bit".


Let's not even get started on pointer aliasing which requires that the optimizer make pessimistic assumptions when pointers are involved (which are *everywhere* if you're doing anything remotely complex) because the compiler can't actually know what might be actually referenced by the pointer. I've seen good compilers generate some horrid code because of the assumptions about pointer aliasing.


C also has a very simple memory model (some might say it's a strength) which makes it difficult to use more interesting memory models (and if you do, there goes *any* hope of portability).


TTFN - Guy
kerravon86@yahoo.com.au [H390-MVS]
2018-02-09 05:06:49 UTC
Permalink
Post by ***@shiresoft.com [H390-MVS]
For some background I've been writing in C since 1977 (Unix v6 days).
The C language has changed *a lot* over time
(v6 -> v7, k&r, ansi, c-89, c-99, etc).
Hi Guy. I am only advocating the use of the first
standardized version of C, ie ANSI C89, as a
replacement for throwing the baby out with the
bathwater and reverting to S/370 assembler
because "hell, C isn't 100% portable in my
opinion, it's only 99.5% portable, may as well
write in assembler which is 100% non-portable".
Post by ***@shiresoft.com [H390-MVS]
The issue with C is that *a lot* is left up to the
compiler. For example, what is the size of an int?
At the point you decide to throw out C and write
in S/370 assembler, the size of an int is exactly
32 bits exactly guaranteed. This assumption
will only bite you when you try to port the code
to a 16-bit micro, not when you try to port to
Unisys.
Post by ***@shiresoft.com [H390-MVS]
Order of bits in a bit-field is completely up to the
compiler.
Not sure why that should be an issue when
porting to Unisys.
Post by ***@shiresoft.com [H390-MVS]
Frankly, the language definition itself has lots of
issues that simple typographical mistakes can
lead to difficult to diagnose bugs (e.g. mis-typing
= for == in a comparison).
A good compiler will give you a warning about
that, and regardless, the competition is with
S/370 assembler, not some theoretically perfect
language. In S/370 you run out of both registers
and addressability, which sucks.
Post by ***@shiresoft.com [H390-MVS]
That's even leaving
off the potential issue of endianness.
That exists with S/370 assembler too.
Post by ***@shiresoft.com [H390-MVS]
Anyone who's actually had to do cross platform
compatibility (or porting) will quickly realize that
C is *not* portable.
It depends on your situation. I ported the 400,000
line GCC compiler from Unix to MVS. If the people
had stuck to the C90 standard my work would have
been even less. I can tell you from first-hand
experience that C is indeed portable. It is
programmers who suck for not following the
standard, when there is an issue at all.
Post by ***@shiresoft.com [H390-MVS]
Trying to write portable C is *hard* and even those
who've been doing it for a long time (in my case
decades) still get "bit".
It depends. I bet if IFOX had been written in C
instead of S/370 assembler it would be a cinch
to run it on Windows. At the end of the day,
IFOX just reads in a bunch of text files and
outputs a single binary file. There is no reason
why that task couldn't have been done in C,
and been a hell of a lot easier to maintain,
given that it has infinite registers, infinite
addressability, and an infinite number of C
programmers available to maintain the code.

For the specific case at hand I don't know. I
don't know the nature of the S/370 file
transfer code that was written in assembler
instead of C.
Post by ***@shiresoft.com [H390-MVS]
Let's not even get started on pointer aliasing
which requires that the optimizer make pessimistic
assumptions when pointers are involved (which
are *everywhere* if you're doing anything remotely
complex) because the compiler can't actually know
what might be actually referenced by the pointer.
I've seen good compilers generate some horrid
code because of the assumptions about pointer
aliasing.
I have never seen IBM C generate anything other
than the most beautiful and efficient S/370+ code
ever. The code is actually TOO efficient, that even
a good assembler programmer will have difficulty
understanding, and need to switch off optimization
if they wish to debug at the assembler level.
Post by ***@shiresoft.com [H390-MVS]
C also has a very simple memory model (some
might say it's a strength) which makes it difficult
to use more interesting memory models (and if
you do, there goes *any* hope of portability).
We're not talking about "more interesting memory
models", we're talking about S/370.

Besides which, C allows you to use a segmented
model like the 8086. Better than coding in 8086
assembler anyway. And your code will still be
portable anyway. That's why things like size_t
exist. More effort has been put into C for such
issues than I can think of in any competing
compiler. Where's the equivalent of size_t in
Cobol or S/370 assembler for when you encounter
a real-world problem of trying to port to Unisys
rather than a theoretical world where 100% of
C is as unportable as S/370 assembler?

BFN. Paul.
Guy Sotomayor Jr ggs@shiresoft.com [H390-MVS]
2018-02-09 06:50:41 UTC
Permalink
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
For some background I've been writing in C since 1977 (Unix v6 days).
The C language has changed *a lot* over time
(v6 -> v7, k&r, ansi, c-89, c-99, etc).
Hi Guy. I am only advocating the use of the first
standardized version of C, ie ANSI C89, as a
replacement for throwing the baby out with the
bathwater and reverting to S/370 assembler
because "hell, C isn't 100% portable in my
opinion, it's only 99.5% portable, may as well
write in assembler which is 100% non-portable”.
I’m taking issue with some of the statement that C is portable.
It is up to a point. Without seeing the code and the destination
platform, I would not assert anything in terms of portability for
C, certainly not in the 99% range.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
The issue with C is that *a lot* is left up to the
compiler. For example, what is the size of an int?
At the point you decide to throw out C and write
in S/370 assembler, the size of an int is exactly
32 bits exactly guaranteed. This assumption
will only bite you when you try to port the code
to a 16-bit micro, not when you try to port to
Unisys.
I understand that the target of this thread has been porting from
S/370 to Unisys but given the general notion of portability (which
you’ve been asserting), you can’t make the assumption of the
size of an int (it could be 16, 32, 64, or what ever).
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Order of bits in a bit-field is completely up to the
compiler.
Not sure why that should be an issue when
porting to Unisys.
Because the ordering of the bits is *completely* up to the
compiler. So if you go from S/370 to Unisys, that is presumably
a different compiler, so there’s no guarantee that the bit order
on S/370 will be the same as on Unisys. Hell, different
compilers on the same platform can order bit fields differently
(I’ve seen it, which is why I *never* use bit fields
same goes
for enums).
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Frankly, the language definition itself has lots of
issues that simple typographical mistakes can
lead to difficult to diagnose bugs (e.g. mis-typing
= for == in a comparison).
A good compiler will give you a warning about
that, and regardless, the competition is with
S/370 assembler, not some theoretically perfect
language. In S/370 you run out of both registers
and addressability, which sucks.
No, a compiler will not give you a warning because both
are valid C constructs. For example:
(a) if (a=b) { foo }
(b) if (a==b) { foo }

If you meant to have (b) the compiler can’t say anything
if you wrote (a) because (a) is completely valid C syntax.

All I’m saying is that C is far from a perfect language and
the above illustrates it. Having two completely different
(and undetectable) behaviors for a type-o.

It was a mistake to have the assignment operator (=)
differ from the equality operator. Other languages at the
time made assignment something like “:=“ and equality
either “=“ or “==“.

C did fix a few things early on. Increment/decrement
used to be =+ and =- vs += and -= as they are now and
they were fixed in the v6->v7 transition. It was pointed
out that = vs == was equally an issue but K&R decided
not to change it.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
That's even leaving
off the potential issue of endianness.
That exists with S/370 assembler too.
Why? In C I don’t know if the representation of a
value is big or little endian and without resorting to
“tricks” code can’t know and can get into trouble by
making assumptions about endian.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Anyone who's actually had to do cross platform
compatibility (or porting) will quickly realize that
C is *not* portable.
It depends on your situation. I ported the 400,000
line GCC compiler from Unix to MVS. If the people
had stuck to the C90 standard my work would have
been even less. I can tell you from first-hand
experience that C is indeed portable. It is
programmers who suck for not following the
standard, when there is an issue at all.
That’s because GCC has been around for a relatively long
period of time and has been ported to a number of different
platforms, so I’m not surprised.

Actually at this point GCC is a pretty antiquated C compiler.
CLANG and LLVM are *much* superior compiler implementations.

The problem with the standard is that it still leaves large “holes”
of either platform or compiler dependent behavior. That *is*
the reason why portability of C is hard
too much of what needs
to be done falls into the grey areas.

As one of my colleagues said many years ago, all C compilers
will accept correct C programs. It is the set of incorrect C programs
that they accept is the source of many portability issues. Said
another way, until I’ve run my code through a number of different
C compilers, I don’t actually know if my code actually conforms to
the standard (and then I’m not 100% sure). gcc (even with the
latest compilers at C99 checking level) accepts a lot of code that
isn’t compliant (to the standard) C code.

That’s why for some environments there are supplemental
standards (such as MISRA see https://en.wikipedia.org/wiki/MISRA_C <https://en.wikipedia.org/wiki/MISRA_C>)
which specify a sub-set of C that avoids the grey areas.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Trying to write portable C is *hard* and even those
who've been doing it for a long time (in my case
decades) still get "bit".
It depends. I bet if IFOX had been written in C
instead of S/370 assembler it would be a cinch
to run it on Windows. At the end of the day,
IFOX just reads in a bunch of text files and
outputs a single binary file. There is no reason
why that task couldn't have been done in C,
and been a hell of a lot easier to maintain,
given that it has infinite registers, infinite
addressability, and an infinite number of C
programmers available to maintain the code.
For the specific case at hand I don't know. I
don't know the nature of the S/370 file
transfer code that was written in assembler
instead of C.
The problem is that there is a lot of legacy code that was written
prior to C being wide spread. Arguing that it should be re-written
in C is silly.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Let's not even get started on pointer aliasing
which requires that the optimizer make pessimistic
assumptions when pointers are involved (which
are *everywhere* if you're doing anything remotely
complex) because the compiler can't actually know
what might be actually referenced by the pointer.
I've seen good compilers generate some horrid
code because of the assumptions about pointer
aliasing.
I have never seen IBM C generate anything other
than the most beautiful and efficient S/370+ code
ever. The code is actually TOO efficient, that even
a good assembler programmer will have difficulty
understanding, and need to switch off optimization
if they wish to debug at the assembler level.
I can’t speak for S/370 as I’ve never written in C for it. But for
the platforms I work on (x86, ARM, PPC, etc) I don’t have a
problem reading (and debugging) the output assembler even
at high optimization levels.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
C also has a very simple memory model (some
might say it's a strength) which makes it difficult
to use more interesting memory models (and if
you do, there goes *any* hope of portability).
We're not talking about "more interesting memory
models", we're talking about S/370.
I’m talking about portability of C in general.
Post by ***@yahoo.com.au [H390-MVS]
Besides which, C allows you to use a segmented
model like the 8086. Better than coding in 8086
assembler anyway. And your code will still be
portable anyway. That's why things like size_t
exist. More effort has been put into C for such
issues than I can think of in any competing
compiler. Where's the equivalent of size_t in
Cobol or S/370 assembler for when you encounter
a real-world problem of trying to port to Unisys
rather than a theoretical world where 100% of
C is as unportable as S/370 assembler?
size_t doesn’t solve the memory model issue.

You’ve obviously never written C code for 8086 or 80286
(or segmented 80386/80486). It’s *ugly* code. Am I dealing
with a small memory model, a large memory model or a
huge memory model?

Different memory models break the assumption of
sizeof(void *) == sizeof(int) which a lot of code makes.

A lot of code also makes assumptions about memory
layout which can also be broken by other memory models.

Having used a lot of different languages, I can say that C
is a very low level systems implementation language. For
things that don’t need to be at that level, I prefer to use a
higher level language that doesn’t suffer from the portability
issues of C.

One of the reasons that C became so widespread was the
fact that there (originally) was a reference compiler (PCC)
*and* that the C runtime was fairly simple, so getting a new
compiler going on a new platform/environment was relatively
simple.

TTFN - Guy
kerravon86@yahoo.com.au [H390-MVS]
2018-02-09 07:47:32 UTC
Permalink
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
I’m taking issue with some of the statement that C is portable.
It is up to a point. Without seeing the code and the destination
platform, I would not assert anything in terms of portability for
C, certainly not in the 99% range.
It depends if you are using C for some low-level
work or for application logic.

If you are using it for application logic, it is in
the 99% range, unlike S/370 assembler which
is in the 0% range.

GCC and IFOX are almost completely application
logic, so literally hundreds of thousands of lines
of code pass through without problem.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
At the point you decide to throw out C and write
in S/370 assembler, the size of an int is exactly
32 bits exactly guaranteed. This assumption
will only bite you when you try to port the code
to a 16-bit micro, not when you try to port to
Unisys.
I understand that the target of this thread has been porting from
S/370 to Unisys but given the general notion of portability (which
you’ve been asserting), you can’t make the assumption of the
size of an int (it could be 16, 32, 64, or what ever).
What you are saying is technically correct.

That doesn't alter the fact that what I said was
technically correct also. At the point you are
thinking of writing in S/370 assembler, where
the size of R2 is exactly 32 bits, C will rise to
that challenge. int is exactly 32 bits too.

Again, that assumption won't bite you in the
bum if you port to Windows, Unix, or MVS.
Or Unisys in this case.

Writing in S/370 assembler will bite you in
the bum from the fist line of code you write,
because you get to rewrite it all again when
it's time to port to Unisys. ALL of it. AGAIN.
You may as well just do it once in C and
watch the beautiful S/370 assembler get
generated, with an infinite number of registers
and infinite addressability.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Order of bits in a bit-field is completely up to the
compiler.
Not sure why that should be an issue when
porting to Unisys.
Because the ordering of the bits is *completely* up to the
compiler. So if you go from S/370 to Unisys, that is presumably
a different compiler, so there’s no guarantee that the bit order
on S/370 will be the same as on Unisys.
I'm lost. Why should you care what the bit order
is on Unisys? And again, C is not being compared
in a vacuum, it is being directly compared to
S/370 assembler. If you use bitfields in S/370
assembler they are set in a fixed order too.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Hell, different
compilers on the same platform can order bit fields differently
(I’ve seen it, which is why I *never* use bit fields
same goes
for enums).
They both work fine.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Frankly, the language definition itself has lots of
issues that simple typographical mistakes can
lead to difficult to diagnose bugs (e.g. mis-typing
= for == in a comparison).
A good compiler will give you a warning about
that, and regardless, the competition is with
S/370 assembler, not some theoretically perfect
language. In S/370 you run out of both registers
and addressability, which sucks.
No, a compiler will not give you a warning because both
(a) if (a=b) { foo }
(b) if (a==b) { foo }
That's precisely why you get a WARNING not
an ERROR. If I show you a good compiler that
generates a warning for (a) above but not (b)
below, will you admit you are wrong?
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
If you meant to have (b) the compiler can’t say anything
if you wrote (a) because (a) is completely valid C syntax.
If you believe C syntax has deficiencies, so
be it, that's in the eye of the beholder. It
doesn't take away anything from C being
portable, especially when faced with the
real world challenge of taking a body of
code from MVS to Unisys. C beats the
pants off S/370 assembler completely and
utterly.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
All I’m saying is that C is far from a perfect language and
I never claimed C was a perfect language.
Only that you should think 1000 times before
you write something in S/370 assembler and
think about writing it in C instead.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
the above illustrates it. Having two completely different
(and undetectable) behaviors for a type-o.
It is detectable, but even if it wasn't, typos in
S/370 assembler aren't detectable either.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
It was a mistake to have the assignment operator (=)
differ from the equality operator. Other languages at the
time made assignment something like “:=“ and equality
either “=“ or “==“.
Maybe. Maybe not. It's a hell of lot easier to
get those things right than it is to get
S/370 assembler right. I'm probably 30 times
more productive in C than assembler, and
more to the point, C programmers are a dime
a dozen.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
That's even leaving
off the potential issue of endianness.
That exists with S/370 assembler too.
Why? In C I don’t know if the representation of a
value is big or little endian and without resorting to
“tricks” code can’t know and can get into trouble by
making assumptions about endian.
Which bit about "that exists with S/370 assembler
too" do you disagree with?
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
That’s because GCC has been around for a relatively long
period of time and has been ported to a number of different
platforms, so I’m not surprised.
So you're not surprised that it is possible
to write 400,000 lines of totally portable
C code if you do it properly?

Thanks. That concludes the case for the
affirmative.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Actually at this point GCC is a pretty antiquated C compiler.
CLANG and LLVM are *much* superior compiler implementations.
Do they have S/370 targets so that they can
run on standard Hercules S/370?
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
The problem with the standard is that it still leaves large “holes”
of either platform or compiler dependent behavior. That *is*
the reason why portability of C is hard
too much of what needs
to be done falls into the grey areas.
Again, 400,000 lines of code can't be wrong.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
As one of my colleagues said many years ago, all C compilers
will accept correct C programs. It is the set of incorrect C programs
that they accept is the source of many portability issues. Said
another way, until I’ve run my code through a number of different
C compilers, I don’t actually know if my code actually conforms to
the standard (and then I’m not 100% sure). gcc (even with the
latest compilers at C99 checking level) accepts a lot of code that
isn’t compliant (to the standard) C code.
Yes, so case in point, you may have to fix 3
bugs when you port the C code from S/370
to Unisys. I'd much rather be in a position of
hiring a Unisys C programmer to fix 3 bugs
than hire a Unisys C programmer to rewrite
an entire body of code in S/370 assembler
(which they don't even know) into C.

Even if you know in advance that when writing
in C on S/370 that you are going to write 3
undetectable bugs, you should STILL write in
C instead of S/370 assembler.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
The problem is that there is a lot of legacy code that was written
prior to C being wide spread. Arguing that it should be re-written
in C is silly.
I'm not. I'm countering people who say that
*even if* C had been available on exactly
the same day that S/370 assembler had
been invented, you should *still* write in
S/370 assembler because it is superior
to C in every way, and just as portable.

It is right now that that attitude has hit a
gigantic brick wall as someone in the real
world has tried to port a body of code to
Unisys.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
I can’t speak for S/370 as I’ve never written in C for it. But for
the platforms I work on (x86, ARM, PPC, etc) I don’t have a
problem reading (and debugging) the output assembler even
at high optimization levels.
Well IBM C is in a class of its own then, with
experienced assembler programmers switching
off optimization to produce assembler code that
is as simple as they would have written
themselves.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
C also has a very simple memory model (some
might say it's a strength) which makes it difficult
to use more interesting memory models (and if
you do, there goes *any* hope of portability).
We're not talking about "more interesting memory
models", we're talking about S/370.
I’m talking about portability of C in general.
And I'm talking about real world usage, of some
poor guy tasked with porting code from MVS
to Unisys, not some theoretically pure language
that beats the pants off C.

The competition is between C and S/370
assembler in this case, and in my opinion, C
beats the pants off S/370 assembler.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
size_t doesn’t solve the memory model issue.
The perhaps you could explain the "issue".
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
You’ve obviously never written C code for 8086 or 80286
(or segmented 80386/80486).
On the contrary, I've not just written code for
8086 and 80386, I've written a friggin ENTIRE
C RUNTIME LIBRARY for BOTH of those,
combined with an ENTIRE OPERATING SYSTEM
for BOTH of those. PDOS/86 and PDOS/386
and PDPCLIB, all available, free and genuine
public domain here:

http://pdos.sourceforge.net
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
It’s *ugly* code. Am I dealing
with a small memory model, a large memory model or a
huge memory model?
You don't need to know. Whatever the application
is that you are trying to write, such as hexdump
or some file transfer application as is the problem
at hand, you just need to follow the rules and
you don't need to care about large etc. You just
rebuild your application in whichever memory
model is most suitable, for whichever processor
is most suitable.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Different memory models break the assumption of
sizeof(void *) == sizeof(int) which a lot of code makes.
You have isolated a problem with some lousy
C programmers. Note that the people who
wrote the 400,000 lines of GCC haven't made
that assumption. This has nothing to do with
C not being portable, and nothing to do with
the specific case at hand of going from S/370
to Unisys.

In addition, it is actually C's strength compared
to all other languages that when you have
pointers, such as your "void *" above, you
should never be in a position of interchanging
pointers and integers, as these things are
kept separate with things like size_t and
pointer incrementing that is done in terms of
what the pointer is pointing to rather than
some integer amount.

It's a beauty to behold.

And again, beats the pants off writing it once
in S/370 assembler and then rewriting it in C
when it's time to move to Unisys.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Having used a lot of different languages, I can say that C
is a very low level systems implementation language. For
things that don’t need to be at that level, I prefer to use a
higher level language that doesn’t suffer from the portability
issues of C.
I don't have a problem with that either. I don't
have a problem with people writing business
applications in Cobol either. What I have an
issue with is people writing application logic
(ie loops) in S/370 assembler when they
should be using C, which has a very good
chance of being ported to other platforms
such as Unisys as a real-world example.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
One of the reasons that C became so widespread was the
fact that there (originally) was a reference compiler (PCC)
*and* that the C runtime was fairly simple, so getting a new
compiler going on a new platform/environment was relatively
simple.
Sounds good to me. And now we have exactly
that with GCCMVS. 400,000 lines of C code
now running natively on S/370.

BFN. Paul.
Bob Bertrand bbertrand007@yahoo.com [H390-MVS]
2018-02-09 09:34:06 UTC
Permalink
I'm curious - how can a C program invoke all of the MVS system interfaces, such as those documented in the Assembler Programmer's Reference manuals, never mind those documented in the Authorized Assembler Programmer's Reference?  I don't know C, so this is an unbiased question.
Thank-you.
On Friday, February 9, 2018, 2:47:38 AM EST, ***@yahoo.com.au [H390-MVS] <H390-***@yahoogroups.com> wrote:

 
I’m taking issue with some of the statement that C is portable..
It is up to a point. Without seeing the code and the destination
platform, I would not assert anything in terms of portability for
C, certainly not in the 99% range.
It depends if you are using C for some low-level
work or for application logic.

If you are using it for application logic, it is in
the 99% range, unlike S/370 assembler which
is in the 0% range.

GCC and IFOX are almost completely application
logic, so literally hundreds of thousands of lines
of code pass through without problem.
Post by ***@yahoo.com.au [H390-MVS]
At the point you decide to throw out C and write
in S/370 assembler, the size of an int is exactly
32 bits exactly guaranteed. This assumption
will only bite you when you try to port the code
to a 16-bit micro, not when you try to port to
Unisys.
I understand that the target of this thread has been porting from
S/370 to Unisys but given the general notion of portability (which
you’ve been asserting), you can’t make the assumption of the
size of an int (it could be 16, 32, 64, or what ever).
What you are saying is technically correct.

That doesn't alter the fact that what I said was
technically correct also. At the point you are
thinking of writing in S/370 assembler, where
the size of R2 is exactly 32 bits, C will rise to
that challenge. int is exactly 32 bits too.

Again, that assumption won't bite you in the
bum if you port to Windows, Unix, or MVS.
Or Unisys in this case.

Writing in S/370 assembler will bite you in
the bum from the fist line of code you write,
because you get to rewrite it all again when
it's time to port to Unisys. ALL of it. AGAIN.
You may as well just do it once in C and
watch the beautiful S/370 assembler get
generated, with an infinite number of registers
and infinite addressability.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Order of bits in a bit-field is completely up to the
compiler.
Not sure why that should be an issue when
porting to Unisys.
Because the ordering of the bits is *completely* up to the
compiler. So if you go from S/370 to Unisys, that is presumably
a different compiler, so there’s no guarantee that the bit order
on S/370 will be the same as on Unisys.
I'm lost. Why should you care what the bit order
is on Unisys? And again, C is not being compared
in a vacuum, it is being directly compared to
S/370 assembler. If you use bitfields in S/370
assembler they are set in a fixed order too.
Hell, different
compilers on the same platform can order bit fields differently
(I’ve seen it, which is why I *never* use bit fields
same goes
for enums).
They both work fine.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Frankly, the language definition itself has lots of
issues that simple typographical mistakes can
lead to difficult to diagnose bugs (e.g. mis-typing
= for == in a comparison).
A good compiler will give you a warning about
that, and regardless, the competition is with
S/370 assembler, not some theoretically perfect
language. In S/370 you run out of both registers
and addressability, which sucks.
No, a compiler will not give you a warning because both
(a) if (a=b) { foo }
(b) if (a==b) { foo }
That's precisely why you get a WARNING not
an ERROR. If I show you a good compiler that
generates a warning for (a) above but not (b)
below, will you admit you are wrong?
If you meant to have (b) the compiler can’t say anything
if you wrote (a) because (a) is completely valid C syntax.
If you believe C syntax has deficiencies, so
be it, that's in the eye of the beholder. It
doesn't take away anything from C being
portable, especially when faced with the
real world challenge of taking a body of
code from MVS to Unisys. C beats the
pants off S/370 assembler completely and
utterly.
All I’m saying is that C is far from a perfect language and
I never claimed C was a perfect language.
Only that you should think 1000 times before
you write something in S/370 assembler and
think about writing it in C instead.
the above illustrates it. Having two completely different
(and undetectable) behaviors for a type-o.
It is detectable, but even if it wasn't, typos in
S/370 assembler aren't detectable either.
It was a mistake to have the assignment operator (=)
differ from the equality operator. Other languages at the
time made assignment something like “:=“ and equality
either “=“ or “==“.
Maybe. Maybe not. It's a hell of lot easier to
get those things right than it is to get
S/370 assembler right. I'm probably 30 times
more productive in C than assembler, and
more to the point, C programmers are a dime
a dozen.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
That's even leaving
off the potential issue of endianness.
That exists with S/370 assembler too.
Why? In C I don’t know if the representation of a
value is big or little endian and without resorting to
“tricks” code can’t know and can get into trouble by
making assumptions about endian.
Which bit about "that exists with S/370 assembler
too" do you disagree with?
That’s because GCC has been around for a relatively long
period of time and has been ported to a number of different
platforms, so I’m not surprised.
So you're not surprised that it is possible
to write 400,000 lines of totally portable
C code if you do it properly?

Thanks. That concludes the case for the
affirmative.
Actually at this point GCC is a pretty antiquated C compiler.
CLANG and LLVM are *much* superior compiler implementations.
Do they have S/370 targets so that they can
run on standard Hercules S/370?
The problem with the standard is that it still leaves large “holes”
of either platform or compiler dependent behavior. That *is*
the reason why portability of C is hard
too much of what needs
to be done falls into the grey areas.
Again, 400,000 lines of code can't be wrong.
As one of my colleagues said many years ago, all C compilers
will accept correct C programs. It is the set of incorrect C programs
that they accept is the source of many portability issues. Said
another way, until I’ve run my code through a number of different
C compilers, I don’t actually know if my code actually conforms to
the standard (and then I’m not 100% sure). gcc (even with the
latest compilers at C99 checking level) accepts a lot of code that
isn’t compliant (to the standard) C code.
Yes, so case in point, you may have to fix 3
bugs when you port the C code from S/370
to Unisys. I'd much rather be in a position of
hiring a Unisys C programmer to fix 3 bugs
than hire a Unisys C programmer to rewrite
an entire body of code in S/370 assembler
(which they don't even know) into C.

Even if you know in advance that when writing
in C on S/370 that you are going to write 3
undetectable bugs, you should STILL write in
C instead of S/370 assembler.
The problem is that there is a lot of legacy code that was written
prior to C being wide spread. Arguing that it should be re-written
in C is silly.
I'm not. I'm countering people who say that
*even if* C had been available on exactly
the same day that S/370 assembler had
been invented, you should *still* write in
S/370 assembler because it is superior
to C in every way, and just as portable.

It is right now that that attitude has hit a
gigantic brick wall as someone in the real
world has tried to port a body of code to
Unisys.
I can’t speak for S/370 as I’ve never written in C for it.. But for
the platforms I work on (x86, ARM, PPC, etc) I don’t have a
problem reading (and debugging) the output assembler even
at high optimization levels.
Well IBM C is in a class of its own then, with
experienced assembler programmers switching
off optimization to produce assembler code that
is as simple as they would have written
themselves.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
C also has a very simple memory model (some
might say it's a strength) which makes it difficult
to use more interesting memory models (and if
you do, there goes *any* hope of portability).
We're not talking about "more interesting memory
models", we're talking about S/370.
I’m talking about portability of C in general.
And I'm talking about real world usage, of some
poor guy tasked with porting code from MVS
to Unisys, not some theoretically pure language
that beats the pants off C.

The competition is between C and S/370
assembler in this case, and in my opinion, C
beats the pants off S/370 assembler.
size_t doesn’t solve the memory model issue.
The perhaps you could explain the "issue".
You’ve obviously never written C code for 8086 or 80286
(or segmented 80386/80486).
On the contrary, I've not just written code for
8086 and 80386, I've written a friggin ENTIRE
C RUNTIME LIBRARY for BOTH of those,
combined with an ENTIRE OPERATING SYSTEM
for BOTH of those. PDOS/86 and PDOS/386
and PDPCLIB, all available, free and genuine
public domain here:

http://pdos.sourceforge.net
Post by ***@yahoo.com.au [H390-MVS]
It’s *ugly* code. Am I dealing
with a small memory model, a large memory model or a
huge memory model?
You don't need to know. Whatever the application
is that you are trying to write, such as hexdump
or some file transfer application as is the problem
at hand, you just need to follow the rules and
you don't need to care about large etc. You just
rebuild your application in whichever memory
model is most suitable, for whichever processor
is most suitable.
Different memory models break the assumption of
sizeof(void *) == sizeof(int) which a lot of code makes.
You have isolated a problem with some lousy
C programmers. Note that the people who
wrote the 400,000 lines of GCC haven't made
that assumption. This has nothing to do with
C not being portable, and nothing to do with
the specific case at hand of going from S/370
to Unisys.

In addition, it is actually C's strength compared
to all other languages that when you have
pointers, such as your "void *" above, you
should never be in a position of interchanging
pointers and integers, as these things are
kept separate with things like size_t and
pointer incrementing that is done in terms of
what the pointer is pointing to rather than
some integer amount.

It's a beauty to behold.

And again, beats the pants off writing it once
in S/370 assembler and then rewriting it in C
when it's time to move to Unisys.
Having used a lot of different languages, I can say that C
is a very low level systems implementation language. For
things that don’t need to be at that level, I prefer to use a
higher level language that doesn’t suffer from the portability
issues of C.
I don't have a problem with that either. I don't
have a problem with people writing business
applications in Cobol either. What I have an
issue with is people writing application logic
(ie loops) in S/370 assembler when they
should be using C, which has a very good
chance of being ported to other platforms
such as Unisys as a real-world example.
One of the reasons that C became so widespread was the
fact that there (originally) was a reference compiler (PCC)
*and* that the C runtime was fairly simple, so getting a new
compiler going on a new platform/environment was relatively
simple.
Sounds good to me. And now we have exactly
that with GCCMVS. 400,000 lines of C code
now running natively on S/370.

BFN. Paul.
'Dave Wade' dave.g4ugm@gmail.com [H390-MVS]
2018-02-09 10:04:04 UTC
Permalink
Bob,



Well of course you can’t do it all in standard “C”, but then its only easy for an assembler programmer because IBM provided macros. You need to do the equivalent for “C”. With some “C” compilers you can include in-line assembler and for some macros that will be enough. For others you may need a small assembler stub, just as you would with any other high level language. Where “C” comes into its own is that you can usually construct the control and fill in the control blocks in “C” keeping the assembler stub very small, typically less than 20 lines of assembler.



Dave



From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: 09 February 2018 09:34
To: ***@yahoo.com.au [H390-MVS] <H390-***@yahoogroups.com>
Subject: Re: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion








I'm curious - how can a C program invoke all of the MVS system interfaces, such as those documented in the Assembler Programmer's Reference manuals, never mind those documented in the Authorized Assembler Programmer's Reference? I don't know C, so this is an unbiased question.



Thank-you.
I’m taking issue with some of the statement that C is portable...
It is up to a point. Without seeing the code and the destination
platform, I would not assert anything in terms of portability for
C, certainly not in the 99% range.
It depends if you are using C for some low-level
work or for application logic.

If you are using it for application logic, it is in
the 99% range, unlike S/370 assembler which
is in the 0% range.

GCC and IFOX are almost completely application
logic, so literally hundreds of thousands of lines
of code pass through without problem.
Post by ***@yahoo.com.au [H390-MVS]
At the point you decide to throw out C and write
in S/370 assembler, the size of an int is exactly
32 bits exactly guaranteed. This assumption
will only bite you when you try to port the code
to a 16-bit micro, not when you try to port to
Unisys.
I understand that the target of this thread has been porting from
S/370 to Unisys but given the general notion of portability (which
you’ve been asserting), you can’t make the assumption of the
size of an int (it could be 16, 32, 64, or what ever).
What you are saying is technically correct.

That doesn't alter the fact that what I said was
technically correct also. At the point you are
thinking of writing in S/370 assembler, where
the size of R2 is exactly 32 bits, C will rise to
that challenge. int is exactly 32 bits too.

Again, that assumption won't bite you in the
bum if you port to Windows, Unix, or MVS.
Or Unisys in this case.

Writing in S/370 assembler will bite you in
the bum from the fist line of code you write,
because you get to rewrite it all again when
it's time to port to Unisys. ALL of it. AGAIN.
You may as well just do it once in C and
watch the beautiful S/370 assembler get
generated, with an infinite number of registers
and infinite addressability.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Order of bits in a bit-field is completely up to the
compiler.
Not sure why that should be an issue when
porting to Unisys.
Because the ordering of the bits is *completely* up to the
compiler. So if you go from S/370 to Unisys, that is presumably
a different compiler, so there’s no guarantee that the bit order
on S/370 will be the same as on Unisys.
I'm lost. Why should you care what the bit order
is on Unisys? And again, C is not being compared
in a vacuum, it is being directly compared to
S/370 assembler. If you use bitfields in S/370
assembler they are set in a fixed order too.
Hell, different
compilers on the same platform can order bit fields differently
(I’ve seen it, which is why I *never* use bit fields
same goes
for enums).
They both work fine.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Frankly, the language definition itself has lots of
issues that simple typographical mistakes can
lead to difficult to diagnose bugs (e.g. mis-typing
= for == in a comparison).
A good compiler will give you a warning about
that, and regardless, the competition is with
S/370 assembler, not some theoretically perfect
language. In S/370 you run out of both registers
and addressability, which sucks.
No, a compiler will not give you a warning because both
(a) if (a=b) { foo }
(b) if (a==b) { foo }
That's precisely why you get a WARNING not
an ERROR. If I show you a good compiler that
generates a warning for (a) above but not (b)
below, will you admit you are wrong?
If you meant to have (b) the compiler can’t say anything
if you wrote (a) because (a) is completely valid C syntax.
If you believe C syntax has deficiencies, so
be it, that's in the eye of the beholder. It
doesn't take away anything from C being
portable, especially when faced with the
real world challenge of taking a body of
code from MVS to Unisys. C beats the
pants off S/370 assembler completely and
utterly.
All I’m saying is that C is far from a perfect language and
I never claimed C was a perfect language.
Only that you should think 1000 times before
you write something in S/370 assembler and
think about writing it in C instead.
the above illustrates it. Having two completely different
(and undetectable) behaviors for a type-o.
It is detectable, but even if it wasn't, typos in
S/370 assembler aren't detectable either.
It was a mistake to have the assignment operator (=)
differ from the equality operator. Other languages at the
time made assignment something like “:=“ and equality
either “=“ or “==“.
Maybe. Maybe not. It's a hell of lot easier to
get those things right than it is to get
S/370 assembler right. I'm probably 30 times
more productive in C than assembler, and
more to the point, C programmers are a dime
a dozen.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
That's even leaving
off the potential issue of endianness.
That exists with S/370 assembler too.
Why? In C I don’t know if the representation of a
value is big or little endian and without resorting to
“tricks” code can’t know and can get into trouble by
making assumptions about endian.
Which bit about "that exists with S/370 assembler
too" do you disagree with?
That’s because GCC has been around for a relatively long
period of time and has been ported to a number of different
platforms, so I’m not surprised.
So you're not surprised that it is possible
to write 400,000 lines of totally portable
C code if you do it properly?

Thanks. That concludes the case for the
affirmative.
Actually at this point GCC is a pretty antiquated C compiler.
CLANG and LLVM are *much* superior compiler implementations.
Do they have S/370 targets so that they can
run on standard Hercules S/370?
The problem with the standard is that it still leaves large “holes”
of either platform or compiler dependent behavior. That *is*
the reason why portability of C is hard
too much of what needs
to be done falls into the grey areas.
Again, 400,000 lines of code can't be wrong.
As one of my colleagues said many years ago, all C compilers
will accept correct C programs. It is the set of incorrect C programs
that they accept is the source of many portability issues. Said
another way, until I’ve run my code through a number of different
C compilers, I don’t actually know if my code actually conforms to
the standard (and then I’m not 100% sure). gcc (even with the
latest compilers at C99 checking level) accepts a lot of code that
isn’t compliant (to the standard) C code.
Yes, so case in point, you may have to fix 3
bugs when you port the C code from S/370
to Unisys. I'd much rather be in a position of
hiring a Unisys C programmer to fix 3 bugs
than hire a Unisys C programmer to rewrite
an entire body of code in S/370 assembler
(which they don't even know) into C.

Even if you know in advance that when writing
in C on S/370 that you are going to write 3
undetectable bugs, you should STILL write in
C instead of S/370 assembler.
The problem is that there is a lot of legacy code that was written
prior to C being wide spread. Arguing that it should be re-written
in C is silly.
I'm not. I'm countering people who say that
*even if* C had been available on exactly
the same day that S/370 assembler had
been invented, you should *still* write in
S/370 assembler because it is superior
to C in every way, and just as portable.

It is right now that that attitude has hit a
gigantic brick wall as someone in the real
world has tried to port a body of code to
Unisys.
I can’t speak for S/370 as I’ve never written in C for it.. But for
the platforms I work on (x86, ARM, PPC, etc) I don’t have a
problem reading (and debugging) the output assembler even
at high optimization levels.
Well IBM C is in a class of its own then, with
experienced assembler programmers switching
off optimization to produce assembler code that
is as simple as they would have written
themselves.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
C also has a very simple memory model (some
might say it's a strength) which makes it difficult
to use more interesting memory models (and if
you do, there goes *any* hope of portability).
We're not talking about "more interesting memory
models", we're talking about S/370.
I’m talking about portability of C in general.
And I'm talking about real world usage, of some
poor guy tasked with porting code from MVS
to Unisys, not some theoretically pure language
that beats the pants off C.

The competition is between C and S/370
assembler in this case, and in my opinion, C
beats the pants off S/370 assembler.
size_t doesn’t solve the memory model issue.
The perhaps you could explain the "issue".
You’ve obviously never written C code for 8086 or 80286
(or segmented 80386/80486).
On the contrary, I've not just written code for
8086 and 80386, I've written a friggin ENTIRE
C RUNTIME LIBRARY for BOTH of those,
combined with an ENTIRE OPERATING SYSTEM
for BOTH of those. PDOS/86 and PDOS/386
and PDPCLIB, all available, free and genuine
public domain here:

http://pdos.sourceforge.net
Post by ***@yahoo.com.au [H390-MVS]
It’s *ugly* code. Am I dealing
with a small memory model, a large memory model or a
huge memory model?
You don't need to know. Whatever the application
is that you are trying to write, such as hexdump
or some file transfer application as is the problem
at hand, you just need to follow the rules and
you don't need to care about large etc. You just
rebuild your application in whichever memory
model is most suitable, for whichever processor
is most suitable.
Different memory models break the assumption of
sizeof(void *) == sizeof(int) which a lot of code makes.
You have isolated a problem with some lousy
C programmers. Note that the people who
wrote the 400,000 lines of GCC haven't made
that assumption. This has nothing to do with
C not being portable, and nothing to do with
the specific case at hand of going from S/370
to Unisys.

In addition, it is actually C's strength compared
to all other languages that when you have
pointers, such as your "void *" above, you
should never be in a position of interchanging
pointers and integers, as these things are
kept separate with things like size_t and
pointer incrementing that is done in terms of
what the pointer is pointing to rather than
some integer amount.

It's a beauty to behold.

And again, beats the pants off writing it once
in S/370 assembler and then rewriting it in C
when it's time to move to Unisys.
Having used a lot of different languages, I can say that C
is a very low level systems implementation language. For
things that don’t need to be at that level, I prefer to use a
higher level language that doesn’t suffer from the portability
issues of C.
I don't have a problem with that either. I don't
have a problem with people writing business
applications in Cobol either. What I have an
issue with is people writing application logic
(ie loops) in S/370 assembler when they
should be using C, which has a very good
chance of being ported to other platforms
such as Unisys as a real-world example.
One of the reasons that C became so widespread was the
fact that there (originally) was a reference compiler (PCC)
*and* that the C runtime was fairly simple, so getting a new
compiler going on a new platform/environment was relatively
simple.
Sounds good to me. And now we have exactly
that with GCCMVS. 400,000 lines of C code
now running natively on S/370.

BFN. Paul.
'M. Khalid Khan' khalidxyz@gmail.com [H390-MVS]
2018-02-09 22:34:50 UTC
Permalink
Dave,
What is the preferred / recommended technique to code a module with
multiple entry points in C ?
Khalid
Post by 'Dave Wade' ***@gmail.com [H390-MVS]
Bob,
Well of course you can’t do it all in standard “C”, but then its only
easy for an assembler programmer because IBM provided macros. You need
to do the >equivalent for “C”. With some “C” compilers you can include
in-line assembler and for some macros that will be enough. For others
you may need a >small assembler stub, just as you would with any other
high level language. Where “C” comes into its own is that you can
usually construct the control >and fill in the control blocks in “C”
keeping the assembler stub very small, typically less than 20 lines of
assembler.
Dave
kerravon86@yahoo.com.au [H390-MVS]
2018-02-10 01:47:01 UTC
Permalink
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
What is the preferred / recommended technique
to code a module with multiple entry points in C ?
This is not something covered by the C90
standard, so if you write code like that, what
is your plan when you need to port your
application to Unix or Unisys?

If you plan in advance for such a move, you'll
probably be able to come up with a solution
that doesn't involve multiple entry points.

Regardless, if you insist on multiple entry
points, I'd suggest that the alias names
still point to the same entry point and you
may need some assembler code to
extract the alias that was used, and then
get C to jump to the different points based
on that. I think REVIEW works that way,
although that is assembler.

BFN. Paul.
'M. Khalid Khan' khalidxyz@gmail.com [H390-MVS]
2018-02-10 17:17:37 UTC
Permalink
Post by ***@yahoo.com.au [H390-MVS]
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
What is the preferred / recommended technique
to code a module with multiple entry points in C ?
This is not something covered by the C90
standard, so if you write code like that, what
is your plan when you need to port your
application to Unix or Unisys?
Why do you assume that there will be a need to port ? As an example TSO
terminal monitor program that comes with at least three entry points (
IKJEFT01, IKJEFT1A & IKJEFT1B ) has been there for around fifty years
without facing portability problems. As a matter of fact most of the
software that I have been involved with did not need porting.
Post by ***@yahoo.com.au [H390-MVS]
If you plan in advance for such a move, you'll
probably be able to come up with a solution
that doesn't involve multiple entry points.
Throwing away a design because C does not support it is not a good
solution. And this simple counterexample demonstrates that C is not all
that it's made out to be. So take it easy and don't get fired up about
what languages OTHERS use for writing their code.

Khalid


------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
kerravon86@yahoo.com.au [H390-MVS]
2018-02-11 01:34:36 UTC
Permalink
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
This is not something covered by the C90
standard, so if you write code like that, what
is your plan when you need to port your
application to Unix or Unisys?
Why do you assume that there will be a need to port ? As an example TSO
terminal monitor program that comes with at least three entry points (
IKJEFT01, IKJEFT1A & IKJEFT1B ) has been there for around fifty years
without facing portability problems.
That is operating system software. We were
discussing application software.
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
As a matter of fact most of the
software that I have been involved with
did not need porting.
If you are writing software directly tied to the
operating system, such as something that
prints MVS ASIDs, you can be pretty
confident it has no use outside of MVS.

But if you have an application, you cannot
predict whether someone will end up
needing to run it on another platform. This
can happen out of the blue, like this exact
Unisys example. You can't even predict
which machine it will need to be ported to.
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
If you plan in advance for such a move, you'll
probably be able to come up with a solution
that doesn't involve multiple entry points.
Throwing away a design because C does not support it is not a good
solution.
Yes it is. Since you will need to throw it away
anyway when it is time to move to Unisys
and you have a system with no such thing
as multiple entry points in a module.
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
And this simple counterexample demonstrates that C is not all
that it's made out to be.
No. This simple example shows you that MVS-specific
S/370 assembler solutions are not all that it is made
out to be.
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
So take it easy and don't get fired up about
what languages OTHERS use for writing their code.
I don't mind what others write their code in so long
as they don't insist that S/370 assembler is just as
portable as C, so that there is no advantage to
writing it in C.

BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-11 01:47:29 UTC
Permalink
Post by ***@yahoo.com.au [H390-MVS]
If you are writing software directly tied to the
operating system, such as something that
prints MVS ASIDs, you can be pretty
confident it has no use outside of MVS.
Actually even that should be written in C,
given that MVS itself, complete with ASIDs,
could be ported to some different hardware.

And if not MVS itself, another flavor of MVS,
such as PDOS/370, which is currently running
on S/370 hardware, but largely written in C,
could be ported to the 80386 one day, complete
with an ASID list.

And if not MVS, then the program that is walking
the ASID list probably does more than just walk
the list, so that other logic may be portable. You
don't know which bit will be ported until you
are told "pack your bags with x, y and z and move
to Unisys".

BFN. Paul.
'M. Khalid Khan' khalidxyz@gmail.com [H390-MVS]
2018-02-11 18:13:54 UTC
Permalink
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
If you are writing software directly tied to the
operating system, such as something that
prints MVS ASIDs, you can be pretty
confident it has no use outside of MVS.
Actually even that should be written in C,
given that MVS itself, complete with ASIDs,
could be ported to some different hardware.
It hasn't happened in 50+ years and is not something I'd worry about. You
off course can go with "if my aunt had ..." possibility.
Post by ***@yahoo.com.au [H390-MVS]
And if not MVS itself, another flavor of MVS,
such as PDOS/370, which is currently running
on S/370 hardware, but largely written in C,
could be ported to the 80386 one day, complete
with an ASID list.
Come back when this OS is able to run some real world application say
claim processing for an insurance company.
Post by ***@yahoo.com.au [H390-MVS]
And if not MVS, then the program that is walking
the ASID list probably does more than just walk
the list, so that other logic may be portable. You
don't know which bit will be ported until you
are told "pack your bags with x, y and z and move
to Unisys".
Not my concern at all since those who can tell me to move to Unisys are
willing to pay for getting it done and don't require any magic wands from
me.
Khalid


------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
kerravon86@yahoo.com.au [H390-MVS]
2018-02-11 18:19:34 UTC
Permalink
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
And if not MVS, then the program that is walking
the ASID list probably does more than just walk
the list, so that other logic may be portable. You
don't know which bit will be ported until you
are told "pack your bags with x, y and z and move
to Unisys".
Not my concern at all since those who can tell me to move to Unisys are
willing to pay for getting it done and don't require any magic wands from
me.
Well, I guess that's where we differ. I don't
like the idea of helping IBM grab my employer
by the balls and increasing the cost of ever
moving to another platform.

BFN. Paul.
'M. Khalid Khan' khalidxyz@gmail.com [H390-MVS]
2018-02-11 20:19:23 UTC
Permalink
Post by ***@yahoo.com.au [H390-MVS]
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
And if not MVS, then the program that is walking
the ASID list probably does more than just walk
the list, so that other logic may be portable. You
don't know which bit will be ported until you
are told "pack your bags with x, y and z and move
to Unisys".
Not my concern at all since those who can tell me to move to Unisys are
willing to pay for getting it done and don't require any magic wands from
me.
Well, I guess that's where we differ. I don't
like the idea of helping IBM grab my employer
by the balls and increasing the cost of ever
moving to another platform.
Get them moved to PDOS then :)

Khalid


------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

'M. Khalid Khan' khalidxyz@gmail.com [H390-MVS]
2018-02-11 17:56:31 UTC
Permalink
Post by ***@yahoo.com.au [H390-MVS]
That is operating system software. We were
discussing application software.
In many cases it applies to non-OS software as well.
Post by ***@yahoo.com.au [H390-MVS]
If you are writing software directly tied to the
operating system, such as something that
prints MVS ASIDs, you can be pretty
confident it has no use outside of MVS.
But if you have an application, you cannot
predict whether someone will end up
needing to run it on another platform. This
can happen out of the blue, like this exact
Unisys example. You can't even predict
which machine it will need to be ported to.
You have no idea about application software, do you ? The application I
currently work on is a claim processing application for health insurance
company written in COBOL and very little assmebler, uses VSAM, DB2, CICS
and batch. No amount of C would have made this application portable. I can
say the same about most of the applications that I have worked with in
last 29 years.
Post by ***@yahoo.com.au [H390-MVS]
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Throwing away a design because C does not support it is not a good
solution.
Yes it is. Since you will need to throw it away
anyway when it is time to move to Unisys
and you have a system with no such thing
as multiple entry points in a module.
No it's not. I'm for exploiting all the facilities offered on a system to
the fullest. Not using something that you have today for the fear that
some day there might be a situation when this facility will not be
available is silly.
Post by ***@yahoo.com.au [H390-MVS]
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
And this simple counterexample demonstrates that C is not all
that it's made out to be.
No. This simple example shows you that MVS-specific
S/370 assembler solutions are not all that it is made
out to be.
I guess there is no cure for a fan-boy.
Post by ***@yahoo.com.au [H390-MVS]
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
So take it easy and don't get fired up about
what languages OTHERS use for writing their code.
I don't mind what others write their code in so long
as they don't insist that S/370 assembler is just as
portable as C, so that there is no advantage to
writing it in C.
I don't know who claimed that assembler code is more portable than C but
it surely wasn't me. Then again the obsession with portability that you
have has little relevance in real world.
Khalid


------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
kerravon86@yahoo.com.au [H390-MVS]
2018-02-11 18:14:02 UTC
Permalink
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
You have no idea about application software, do you ? The application I
currently work on is a claim processing application for health insurance
company written in COBOL and very little assmebler, uses VSAM, DB2, CICS
and batch. No amount of C would have made this application portable. I can
say the same about most of the applications that I have worked with in
last 29 years.
I would have thought the bulk of the above
was already portable. Cobol should be
available on Unisys, SQL is standard, even
if you use extensions, and maybe Mike Noel
needs to port KICKS (written mostly in C)
to Linux/x64 if CICS hasn't been ported there.
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
Yes it is. Since you will need to throw it away
anyway when it is time to move to Unisys
and you have a system with no such thing
as multiple entry points in a module.
No it's not. I'm for exploiting all the facilities offered on a system to
the fullest. Not using something that you have today for the fear that
some day there might be a situation when this facility will not be
available is silly.
It depends on the situation. But you can exploit
a facility using an assembler routine and keep
the (low-level) application logic in C.
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
I don't know who claimed that assembler code is more portable than C but
it surely wasn't me.
Equal, not "more", but I'm not talking about you.
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Then again the obsession with portability that you
have has little relevance in real world.
This thread IS the real world. Unless you are
happy about IBM having you by the balls, you
should pencil in an escape route to an
alternative platform. This is as obvious as the
Y2K problem was for more than a decade
before Y2K.

BFN. Paul.
'M. Khalid Khan' khalidxyz@gmail.com [H390-MVS]
2018-02-11 20:16:58 UTC
Permalink
Post by ***@yahoo.com.au [H390-MVS]
I would have thought the bulk of the above
was already portable. Cobol should be
available on Unisys, SQL is standard, even
if you use extensions, and maybe Mike Noel
needs to port KICKS (written mostly in C)
to Linux/x64 if CICS hasn't been ported there.
In theory there is no difference between theory and practice, in practice
there is. Just because COBOL is available on two systems does not mean
that porting will be trivial or even easy. I'm saying this after being
involved in porting of two COBOL applications ( Burrough's to Unix and ICL
to MVS ). SQL standard is another such idea that does not hold much water
in reality. If relational databases were really so portable everyone would
be running one of the many free databases instead of paying IBM / Oracle
through the nose. As for KICKS all I'd say is not to count your chickens
before they are hatched, let it first run on Unisys and demonstrate that
it can handle the kind of workload that CICS does.
Post by ***@yahoo.com.au [H390-MVS]
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
Yes it is. Since you will need to throw it away
anyway when it is time to move to Unisys
and you have a system with no such thing
as multiple entry points in a module.
No it's not. I'm for exploiting all the facilities offered on a system to
the fullest. Not using something that you have today for the fear that
some day there might be a situation when this facility will not be
available is silly.
It depends on the situation. But you can exploit
a facility using an assembler routine and keep
the (low-level) application logic in C.
Yes, it depends but OS facilities are not the only thing applications
depend on, the whole environment under which an application runs is a
possible dependency.
Post by ***@yahoo.com.au [H390-MVS]
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Then again the obsession with portability that you
have has little relevance in real world.
This thread IS the real world. Unless you are
happy about IBM having you by the balls, you
should pencil in an escape route to an
alternative platform. This is as obvious as the
Y2K problem was for more than a decade
before Y2K.
And part of the reality assessment also involves frequency / likelyhood of
such occurrence. One flower does not make spring and one valid instance of
need of conversion does not warrant that everything should be looked from
that perspective. Like it or not any real world software is more closely
tied to its environment that you would like unless it's a trivial one such
as counting the words in a text file.

Khalid


------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
'Dave Wade' dave.g4ugm@gmail.com [H390-MVS]
2018-02-10 10:55:07 UTC
Permalink
Khalid,

Not what you are asking, or why. “C” program always loads in MAIN. It can test the content of the first token of the command line that invoked it and do different things depending on how it was called.

Dave



From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: 09 February 2018 22:35
To: H390-***@yahoogroups.com
Subject: Re: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion








Dave,

What is the preferred / recommended technique to code a module with multiple entry points in C ?

Khalid





On Fri, 09 Feb 2018 04:04:04 -0600, 'Dave Wade' ***@gmail.com <mailto:***@gmail.com> [H390-MVS] <H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> > wrote:





Bob,



Well of course you can’t do it all in standard “C”, but then its only easy for an assembler programmer because IBM provided macros. You need to do the equivalent for “C”. With some “C” compilers you can include in-line assembler and for some macros that will be enough. For others you may need a small assembler stub, just as you would with any other high level language. Where “C” comes into its own is that you can usually construct the control and fill in the control blocks in “C” keeping the assembler stub very small, typically less than 20 lines of assembler.



Dave
kerravon86@yahoo.com.au [H390-MVS]
2018-02-09 12:16:51 UTC
Permalink
Post by Bob Bertrand ***@yahoo.com [H390-MVS]
I'm curious - how can a C program invoke all
of the MVS system interfaces, such as those
documented in the Assembler Programmer's
Reference manuals, never mind those documented
in the Authorized Assembler Programmer's
Reference? I don't know C, so this is an unbiased
question.
It is a feature/shortcoming of MVS that unlike
Windows and Unix, access to all those OS
services is only provided with an assembler
interface.

That is no reason to be suckered into writing
an entire application in assembler. You instead
just need to write bits of it that access these
facilities, bearing in mind that these facilities
won't exist when you end up having to move
to Unisys etc, so you may as well think about
this clearly up-front.

When I originally wrote PDPCLIB, my C runtime
library for a variety of platforms, including MVS,
the MVS assembler stubs were quite simple
and you can see them below. They worked fine
for my purposes at the time, but have since
morphed into extremely sophisticated assembler
too big to show. The current CMS and DOS/VS
and MUSIC/SP versions are still small though
if you would like to see them.

And of course, that's just the C runtime library.
The actual C application programmer is shielded
from that altogether if they "just" want to write
an assembler like IFOX.

Let me know if this doesn't answer the question
adequately. Note that Dave has also answered the
question.

BFN. Paul.




**********************************************************************
* *
* THIS PROGRAM WRITTEN BY PAUL EDWARDS. *
* RELEASED TO THE PUBLIC DOMAIN *
* *
**********************************************************************
**********************************************************************
* *
* MVSSUPA - SUPPORT ROUTINES FOR PDPCLIB UNDER MVS *
* *
**********************************************************************
@@AOPEN AMODE 31
@@AOPEN RMODE ANY
@@AOPEN CSECT
PRINT NOGEN
YREGS
SUBPOOL EQU 0
SAVE (14,12),,@@AOPEN_&SYSDATE
LR R12,R15
USING @@AOPEN,R12
LR R11,R1
GETMAIN RU,LV=WORKLEN,SP=SUBPOOL
ST R13,4(R1)
ST R1,8(R13)
LR R13,R1
LR R1,R11
USING WORKAREA,R13
*
L R3,0(R1) R3 POINTS TO DDNAME
L R4,4(R1) R4 POINTS TO MODE
L R5,8(R1) R5 POINTS TO RECFM
L R8,12(R1) R8 POINTS TO LRECL
GETMAIN RU,LV=ZDCBLEN,SP=SUBPOOL,LOC=BELOW
LR R2,R1
L R6,0(R4)
LTR R6,R6
BNZ WRITING
* READING
USING ZDCBAREA,R2
MVC ZDCBAREA(INDCBLN),INDCB
MVC EOFR24(EOFRLEN),ENDFILE
LA R4,EOFR24
USING IHADCB,R2
MVC DCBDDNAM,0(R3)
MVC OPENMB,OPENMAC
STCM R4,B'0111',DCBEODA
OPEN ((R2),INPUT),MF=(E,OPENMB),MODE=31
B DONEOPEN
WRITING DS 0H
USING ZDCBAREA,R2
MVC ZDCBAREA(OUTDCBLN),OUTDCB
USING IHADCB,R2
MVC DCBDDNAM,0(R3)
MVC WOPENMB,WOPENMAC
OPEN ((R2),OUTPUT),MF=(E,WOPENMB),MODE=31
DONEOPEN DS 0H
SR R6,R6
LH R6,DCBLRECL
ST R6,0(R8)
SR R6,R6
IC R6,DCBRECFM
LA R7,DCBRECF
NR R6,R7
BZ VARIABLE
L R6,=F'0'
B DONESET
VARIABLE DS 0H
L R6,=F'1'
DONESET DS 0H
ST R6,0(R5)
LR R15,R2
B RETURN
*
* THIS IS NOT EXECUTED DIRECTLY, BUT COPIED INTO 24-BIT STORAGE
ENDFILE LA R6,1
BR R14
EOFRLEN EQU *-ENDFILE
*
RETURN DS 0H
LR R1,R13
L R13,SAVEAREA+4
LR R14,R15
FREEMAIN RU,LV=WORKLEN,A=(R1),SP=SUBPOOL
LR R15,R14
RETURN (14,12),RC=(15)
LTORG
OPENMAC OPEN (,INPUT),MF=L,MODE=31
OPENMLN EQU *-OPENMAC
WOPENMAC OPEN (,OUTPUT),MF=L,MODE=31
WOPENMLN EQU *-WOPENMAC
INDCB DCB MACRF=GL,DSORG=PS,EODAD=ENDFILE
INDCBLN EQU *-INDCB
OUTDCB DCB MACRF=PL,DSORG=PS
OUTDCBLN EQU *-OUTDCB
*
*
*
@@AREAD AMODE 31
@@AREAD RMODE ANY
@@AREAD CSECT
PRINT NOGEN
SAVE (14,12),,@@AREAD_&SYSDATE
LR R12,R15
USING @@AREAD,R12
LR R11,R1
GETMAIN RU,LV=WORKLEN,SP=SUBPOOL
ST R13,4(R1)
ST R1,8(R13)
LR R13,R1
LR R1,R11
USING WORKAREA,R13
*
L R2,0(R1) R2 CONTAINS HANDLE
L R3,4(R1) R3 POINTS TO BUF POINTER
LA R6,0
GET (R2)
ST R1,0(R3)
LR R15,R6
B RETURN2
*
RETURN2 DS 0H
LR R1,R13
L R13,SAVEAREA+4
LR R14,R15
FREEMAIN RU,LV=WORKLEN,A=(R1),SP=SUBPOOL
LR R15,R14
RETURN (14,12),RC=(15)
*
*
*
@@AWRITE AMODE 31
@@AWRITE RMODE ANY
@@AWRITE CSECT
PRINT NOGEN
SAVE (14,12),,@@AWRITE_&SYSDATE
LR R12,R15
USING @@AWRITE,R12
LR R11,R1
GETMAIN RU,LV=WORKLEN,SP=SUBPOOL
ST R13,4(R1)
ST R1,8(R13)
LR R13,R1
LR R1,R11
USING WORKAREA,R13
*
L R2,0(R1) R2 CONTAINS HANDLE
L R3,4(R1) R3 POINTS TO BUF POINTER
PUT (R2)
ST R1,0(R3)
LA R15,0
B RETURNWR
*
RETURNWR DS 0H
LR R1,R13
L R13,SAVEAREA+4
LR R14,R15
FREEMAIN RU,LV=WORKLEN,A=(R1),SP=SUBPOOL
LR R15,R14
RETURN (14,12),RC=(15)
*
*
*
@@ACLOSE AMODE 31
@@ACLOSE RMODE ANY
@@ACLOSE CSECT
PRINT NOGEN
SAVE (14,12),,@@ACLOSE_&SYSDATE
LR R12,R15
USING @@ACLOSE,R12
LR R11,R1
GETMAIN RU,LV=WORKLEN,SP=SUBPOOL
ST R13,4(R1)
ST R1,8(R13)
LR R13,R1
LR R1,R11
USING WORKAREA,R13
*
L R2,0(R1) R2 CONTAINS HANDLE
N R2,=X'7FFFFFFF'
MVC CLOSEMB,CLOSEMAC
CLOSE ((R2)),MF=(E,CLOSEMB),MODE=31
FREEMAIN RU,LV=ZDCBLEN,A=(R2),SP=SUBPOOL
LA R15,0
B RETURN3
*
RETURN3 DS 0H
LR R1,R13
L R13,SAVEAREA+4
LR R14,R15
FREEMAIN RU,LV=WORKLEN,A=(R1),SP=SUBPOOL
LR R15,R14
RETURN (14,12),RC=(15)
LTORG
CLOSEMAC CLOSE (),MF=L,MODE=31
CLOSEMLN EQU *-CLOSEMAC
*
*
*
**********************************************************************
* *
* GETM - GET MEMORY *
* *
**********************************************************************
@@GETM AMODE 31
@@GETM RMODE ANY
@@GETM CSECT
PRINT NOGEN
SAVE (14,12),,@@GETM_&SYSDATE
LR R12,R15
USING @@GETM,R12
*
L R2,0(R1)
L R3,0(R2)
A R3,=F'16'
GETMAIN RU,LV=(R3),SP=SUBPOOL
ST R3,0(R1)
A R1,=F'16'
LR R15,R1
*
RETURNGM DS 0H
RETURN (14,12),RC=(15)
LTORG
*
*
*
**********************************************************************
* *
* FREEM - FREE MEMORY *
* *
**********************************************************************
@@FREEM AMODE 31
@@FREEM RMODE ANY
@@FREEM CSECT
PRINT NOGEN
SAVE (14,12),,@@FREEM_&SYSDATE
LR R12,R15
USING @@FREEM,R12
*
L R2,0(R1)
S R2,=F'16'
L R3,0(R2)
FREEMAIN RU,LV=(R3),A=(R2),SP=SUBPOOL
*
RETURNFM DS 0H
RETURN (14,12),RC=(15)
LTORG
*
*
*
**********************************************************************
* *
* GETCLCK - GET THE VALUE OF THE MVS CLOCK TIMER AND MOVE IT TO AN *
* 8-BYTE FIELD. THIS 8-BYTE FIELD DOES NOT NEED TO BE ALIGNED IN *
* ANY PARTICULAR WAY. *
* *
* E.G. CALL 'GETCLCK' USING WS-CLOCK1 *
* *
* THIS FUNCTION ALSO RETURNS THE NUMBER OF SECONDS SINCE 1970-01-01 *
* BY USING SOME EMPERICALLY-DERIVED MAGIC NUMBERS *
* *
**********************************************************************
@@GETCLK AMODE 31
@@GETCLK RMODE ANY
@@GETCLK CSECT
PRINT NOGEN
SAVE (14,12),,@@GETCLK_&SYSDATE
LR R12,R15
USING @@GETCLK,R12
*
L R2,0(R1)
STCK 0(R2)
L R4,0(R2)
L R5,4(R2)
SRDL R4,12
SL R4,=X'0007D910'
D R4,=F'1000000'
SL R5,=F'1220'
LR R15,R5
*
RETURNGC DS 0H
RETURN (14,12),RC=(15)
LTORG
WORKAREA DSECT
SAVEAREA DS 18F
DS 0F
CLOSEMB DS CL(CLOSEMLN)
DS 0F
OPENMB DS CL(OPENMLN)
DS 0F
WOPENMB DS CL(WOPENMLN)
WORKLEN EQU *-WORKAREA
ZDCBAREA DSECT
DS CL(INDCBLN)
DS CL(OUTDCBLN)
DS 0H
EOFR24 DS CL(EOFRLEN)
ZDCBLEN EQU *-ZDCBAREA
DCBD DSORG=PS
END
Joe Monk joemonk64@gmail.com [H390-MVS]
2018-02-09 16:44:17 UTC
Permalink
Bob,

On the mainframe, IBM has a version of C called Metal C. This version uses
standard OS linkage conventions to call system functions. So, any interface
documented can be called just the same as if you were calling from
assembler.

Joe
Post by Bob Bertrand ***@yahoo.com [H390-MVS]
I'm curious - how can a C program invoke all of the MVS system interfaces,
such as those documented in the Assembler Programmer's Reference manuals,
never mind those documented in the Authorized Assembler Programmer's
Reference? I don't know C, so this is an unbiased question.
Thank-you.
I’m taking issue with some of the statement that C is portable....
It is up to a point. Without seeing the code and the destination
platform, I would not assert anything in terms of portability for
C, certainly not in the 99% range.
It depends if you are using C for some low-level
work or for application logic.
If you are using it for application logic, it is in
the 99% range, unlike S/370 assembler which
is in the 0% range.
GCC and IFOX are almost completely application
logic, so literally hundreds of thousands of lines
of code pass through without problem.
Post by ***@yahoo.com.au [H390-MVS]
At the point you decide to throw out C and write
in S/370 assembler, the size of an int is exactly
32 bits exactly guaranteed. This assumption
will only bite you when you try to port the code
to a 16-bit micro, not when you try to port to
Unisys.
I understand that the target of this thread has been porting from
S/370 to Unisys but given the general notion of portability (which
you’ve been asserting), you can’t make the assumption of the
size of an int (it could be 16, 32, 64, or what ever).
What you are saying is technically correct.
That doesn't alter the fact that what I said was
technically correct also. At the point you are
thinking of writing in S/370 assembler, where
the size of R2 is exactly 32 bits, C will rise to
that challenge. int is exactly 32 bits too.
Again, that assumption won't bite you in the
bum if you port to Windows, Unix, or MVS.
Or Unisys in this case.
Writing in S/370 assembler will bite you in
the bum from the fist line of code you write,
because you get to rewrite it all again when
it's time to port to Unisys. ALL of it. AGAIN.
You may as well just do it once in C and
watch the beautiful S/370 assembler get
generated, with an infinite number of registers
and infinite addressability.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Order of bits in a bit-field is completely up to the
compiler.
Not sure why that should be an issue when
porting to Unisys.
Because the ordering of the bits is *completely* up to the
compiler. So if you go from S/370 to Unisys, that is presumably
a different compiler, so there’s no guarantee that the bit order
on S/370 will be the same as on Unisys.
I'm lost. Why should you care what the bit order
is on Unisys? And again, C is not being compared
in a vacuum, it is being directly compared to
S/370 assembler. If you use bitfields in S/370
assembler they are set in a fixed order too.
Hell, different
compilers on the same platform can order bit fields differently
(I’ve seen it, which is why I *never* use bit fields
same goes
for enums).
They both work fine.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Frankly, the language definition itself has lots of
issues that simple typographical mistakes can
lead to difficult to diagnose bugs (e.g. mis-typing
= for == in a comparison).
A good compiler will give you a warning about
that, and regardless, the competition is with
S/370 assembler, not some theoretically perfect
language. In S/370 you run out of both registers
and addressability, which sucks.
No, a compiler will not give you a warning because both
(a) if (a=b) { foo }
(b) if (a==b) { foo }
That's precisely why you get a WARNING not
an ERROR. If I show you a good compiler that
generates a warning for (a) above but not (b)
below, will you admit you are wrong?
If you meant to have (b) the compiler can’t say anything
if you wrote (a) because (a) is completely valid C syntax.
If you believe C syntax has deficiencies, so
be it, that's in the eye of the beholder. It
doesn't take away anything from C being
portable, especially when faced with the
real world challenge of taking a body of
code from MVS to Unisys. C beats the
pants off S/370 assembler completely and
utterly.
All I’m saying is that C is far from a perfect language and
I never claimed C was a perfect language.
Only that you should think 1000 times before
you write something in S/370 assembler and
think about writing it in C instead.
the above illustrates it. Having two completely different
(and undetectable) behaviors for a type-o.
It is detectable, but even if it wasn't, typos in
S/370 assembler aren't detectable either.
It was a mistake to have the assignment operator (=)
differ from the equality operator. Other languages at the
time made assignment something like “:=“ and equality
either “=“ or “==“.
Maybe. Maybe not. It's a hell of lot easier to
get those things right than it is to get
S/370 assembler right. I'm probably 30 times
more productive in C than assembler, and
more to the point, C programmers are a dime
a dozen.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
That's even leaving
off the potential issue of endianness.
That exists with S/370 assembler too.
Why? In C I don’t know if the representation of a
value is big or little endian and without resorting to
“tricks” code can’t know and can get into trouble by
making assumptions about endian.
Which bit about "that exists with S/370 assembler
too" do you disagree with?
That’s because GCC has been around for a relatively long
period of time and has been ported to a number of different
platforms, so I’m not surprised.
So you're not surprised that it is possible
to write 400,000 lines of totally portable
C code if you do it properly?
Thanks. That concludes the case for the
affirmative.
Actually at this point GCC is a pretty antiquated C compiler.
CLANG and LLVM are *much* superior compiler implementations.
Do they have S/370 targets so that they can
run on standard Hercules S/370?
The problem with the standard is that it still leaves large “holes”
of either platform or compiler dependent behavior. That *is*
the reason why portability of C is hard
too much of what needs
to be done falls into the grey areas.
Again, 400,000 lines of code can't be wrong.
As one of my colleagues said many years ago, all C compilers
will accept correct C programs. It is the set of incorrect C programs
that they accept is the source of many portability issues. Said
another way, until I’ve run my code through a number of different
C compilers, I don’t actually know if my code actually conforms to
the standard (and then I’m not 100% sure). gcc (even with the
latest compilers at C99 checking level) accepts a lot of code that
isn’t compliant (to the standard) C code.
Yes, so case in point, you may have to fix 3
bugs when you port the C code from S/370
to Unisys. I'd much rather be in a position of
hiring a Unisys C programmer to fix 3 bugs
than hire a Unisys C programmer to rewrite
an entire body of code in S/370 assembler
(which they don't even know) into C.
Even if you know in advance that when writing
in C on S/370 that you are going to write 3
undetectable bugs, you should STILL write in
C instead of S/370 assembler.
The problem is that there is a lot of legacy code that was written
prior to C being wide spread. Arguing that it should be re-written
in C is silly.
I'm not. I'm countering people who say that
*even if* C had been available on exactly
the same day that S/370 assembler had
been invented, you should *still* write in
S/370 assembler because it is superior
to C in every way, and just as portable.
It is right now that that attitude has hit a
gigantic brick wall as someone in the real
world has tried to port a body of code to
Unisys.
I can’t speak for S/370 as I’ve never written in C for it. But for
the platforms I work on (x86, ARM, PPC, etc) I don’t have a
problem reading (and debugging) the output assembler even
at high optimization levels.
Well IBM C is in a class of its own then, with
experienced assembler programmers switching
off optimization to produce assembler code that
is as simple as they would have written
themselves.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
C also has a very simple memory model (some
might say it's a strength) which makes it difficult
to use more interesting memory models (and if
you do, there goes *any* hope of portability).
We're not talking about "more interesting memory
models", we're talking about S/370.
I’m talking about portability of C in general.
And I'm talking about real world usage, of some
poor guy tasked with porting code from MVS
to Unisys, not some theoretically pure language
that beats the pants off C.
The competition is between C and S/370
assembler in this case, and in my opinion, C
beats the pants off S/370 assembler.
size_t doesn’t solve the memory model issue.
The perhaps you could explain the "issue".
You’ve obviously never written C code for 8086 or 80286
(or segmented 80386/80486).
On the contrary, I've not just written code for
8086 and 80386, I've written a friggin ENTIRE
C RUNTIME LIBRARY for BOTH of those,
combined with an ENTIRE OPERATING SYSTEM
for BOTH of those. PDOS/86 and PDOS/386
and PDPCLIB, all available, free and genuine
http://pdos.sourceforge.net
Post by ***@yahoo.com.au [H390-MVS]
It’s *ugly* code. Am I dealing
with a small memory model, a large memory model or a
huge memory model?
You don't need to know. Whatever the application
is that you are trying to write, such as hexdump
or some file transfer application as is the problem
at hand, you just need to follow the rules and
you don't need to care about large etc. You just
rebuild your application in whichever memory
model is most suitable, for whichever processor
is most suitable.
Different memory models break the assumption of
sizeof(void *) == sizeof(int) which a lot of code makes.
You have isolated a problem with some lousy
C programmers. Note that the people who
wrote the 400,000 lines of GCC haven't made
that assumption. This has nothing to do with
C not being portable, and nothing to do with
the specific case at hand of going from S/370
to Unisys.
In addition, it is actually C's strength compared
to all other languages that when you have
pointers, such as your "void *" above, you
should never be in a position of interchanging
pointers and integers, as these things are
kept separate with things like size_t and
pointer incrementing that is done in terms of
what the pointer is pointing to rather than
some integer amount.
It's a beauty to behold.
And again, beats the pants off writing it once
in S/370 assembler and then rewriting it in C
when it's time to move to Unisys.
Having used a lot of different languages, I can say that C
is a very low level systems implementation language. For
things that don’t need to be at that level, I prefer to use a
higher level language that doesn’t suffer from the portability
issues of C.
I don't have a problem with that either. I don't
have a problem with people writing business
applications in Cobol either. What I have an
issue with is people writing application logic
(ie loops) in S/370 assembler when they
should be using C, which has a very good
chance of being ported to other platforms
such as Unisys as a real-world example.
One of the reasons that C became so widespread was the
fact that there (originally) was a reference compiler (PCC)
*and* that the C runtime was fairly simple, so getting a new
compiler going on a new platform/environment was relatively
simple.
Sounds good to me. And now we have exactly
that with GCCMVS. 400,000 lines of C code
now running natively on S/370.
BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-10 01:28:07 UTC
Permalink
Post by Joe Monk ***@gmail.com [H390-MVS]
On the mainframe, IBM has a version of C called
Metal C. This version uses standard OS linkage
conventions to call system functions. So, any
interface documented can be called just the same
as if you were calling from assembler.
That would only work for functions that are specified
as callable routines, not the many macros like OPEN
that are the normal interface to MVS facilities.

BFN. Paul.
Joe Monk joemonk64@gmail.com [H390-MVS]
2018-02-10 02:00:49 UTC
Permalink
I would expect a metal 'C' routine using MVS interfaces to look like this....

This is not my code, but an example I found...

/*********************************************************************
* readds.c *
* Purpose: Read the records of a VSAM data set and write them *
* to a sequential Data Set *
* *
* Input: SYSUT1 DD statement describing a Sequential Data Set *
* with DISP=SHR *
* SYSPRINT DD statement that any messages will be written *
* to. *
* by Andrew Wilt *
*********************************************************************/

#include <string.h> /* for memcpy, memset, strlen */
#include "ihadcb.h" /* IHADCB mapping */

/* statically define the DCB parameter list for a DCB that
describes using QSAM I/O to a sequential dataset. The DCB
is defined for output (PUTs). The output data set is a
Variable Blocked data set (SYSOUT=*). A dummy DCBE address
is coded so that the appropriate bits indicating that a
DCBE exists are set.
*/
__asm(
" DCB DSORG=PS,MACRF=(PL),DCBE=2,"
"RECFM=VBA,LRECL=137"
: "DS"(stoutdcb));

/* statically define a DCBE for association with the DCB */
__asm(
" DCBE LOC=ANY,SYNAD=QSAMIOER,RMODE31=BUFF,BLOCKTOKENSIZE=LARGE,"
"EADSCB=OK,EODAD=QSAMEOD"
: "DS"(STDCBE));

/* statically define the DCB parameter list for a DCB that
describes using QSAM I/O to a sequential dataset. The DCB
is defined for input (GETs). */
__asm(
" DCB DSORG=PS,MACRF=(GL),DCBE=2"
: "DS"(stindcb));

/* statically define the OPEN parameter list for opening the
QSAM output DD. The long form of the parameter list (MODE=31)
is requested so that the module can be AMODE 31. */
__asm(
" OPEN (,(OUTPUT)),MF=L,MODE=31" : "DS"(open_output));

/* statically define the OPEN parameter list for opening the
input DD. The long form of the parameter list (MODE=31)
is requested so that the module can be AMODE 31.*/
__asm(
" OPEN (,(INPUT)),MF=L,MODE=31" : "DS"(open_input));

/* statically define the CLOSE parameter list for closing the
QSAM output DD. The long form of the parameter list (MODE=31)
is requested so that the module can be AMODE 31. */
__asm(
" CLOSE (),MF=L,MODE=31" : "DS"(close_static) );

#define null 0
#define kASALineFeed ' ' /* Line Feed for ASA control */
#define kASA2LineFeed '0' /* Line Feed 2 lines ASA control */
#define kASA3LineFeed '-' /* Line Feed 3 lines ASA control */
#define kMAXLRECL 32760 /* Maximum Logical Record Length */
#define kParmList 1024
#define kDCBElen 56 /* Length of a DCBE */
int max(int x, int y){
return x > y ? x : y;
}
int min(int x, int y){
return x < y ? x : y;
}

/* function prototype for Open QSAM DCB */
struct ihadcb* open_QSAM_dcb(char*, char);
/* function prototype for Close QSAM DCB */
int close_QSAM_dcb(struct ihadcb*);
/* function prototype for reading QSAM Data Set functionality */
int read_QSAM_dataset(struct ihadcb* in, struct ihadcb* out);

/* Main Line code */
int main(void* USRPARM){
/* ensure that the user parm is not padded with extra bytes */
#pragma pack(packed)
/* option values passed via PARM= JCL parameter */
typedef struct opts{
unsigned short optlen;
char optlist[100];
} ;
struct opts *loc_opts;
#pragma pack(reset)

char SYSPRINTdd[9];
char SYSUT1dd[9];
struct ihadcb *sysPRdcbp; /* Pointer to SYSPRINT DCB */
struct ihadcb* sysUT1dcbp; /* Pointer to SYSUT1 DCB */
int retcode = 0;
int total_written; /* total number of bytes written
to the output data set */
/* Begin Mainline Code */
memcpy(SYSPRINTdd, "SYSPRINT", 9); /* Set the SYSPRINT DCB name */
memcpy(SYSUT1dd, "SYSUT1 ", 9); /* Set the SYSUT1 DCB name */

/* Open SYSPRINT DD for QSAM Output. A pointer to a DCB block is
* returned upon a successful open. */
sysPRdcbp = open_QSAM_dcb(SYSPRINTdd,'o');

/* Open the VSAM data set specified on the SYSUT1 DD statement.
* A pointer to an ACB is returned upon a successful open. */
sysUT1dcbp = open_QSAM_dcb(SYSUT1dd,'i');

/* Read the data set and write its contents to the
* output DD.
*/
if(sysUT1dcbp != null &&
sysPRdcbp != null){
total_written = read_QSAM_dataset(sysUT1dcbp, sysPRdcbp);

/* Close SYSPRINT DCB */
retcode = max(retcode, close_QSAM_dcb(sysPRdcbp));
sysPRdcbp = null;
/* Close SYSUT1 data Set */
retcode = max(retcode, close_QSAM_dcb(sysUT1dcbp));
sysPRdcbp = null;
} else
retcode = 16;
return retcode;
}

/* Functionality to read records from sequential data set and
* write them to the output Sequential data set.
* Input: Pointer to Opened Input DCB
* Pointer to Opened Output DCB
* Output: Number of bytes written.
*/
/* Request that the compiler insert the default prolog
and epilog code to get and free autodata storage */
#pragma prolog(read_QSAM_dataset,"MYPROLOG")
#pragma epilog(read_QSAM_dataset,"MYEPILOG")
int read_QSAM_dataset(struct ihadcb* in, struct ihadcb* out){
int bytes_written=0;
int readlen = 0;
char *buff;
#pragma pack(packed)
struct qsamrec{
short qs_rdw; /* Record Descriptor Word */
short qs_filler; /* Two byte reserved field */
char qs_asa; /* ASA control character */
char qs_buff[kMAXLRECL]; /* Message buffer */
};
#pragma pack(reset)
struct qsamrec *outrec;
/* fields to know if EOF has been reached, or there was an I/O err */
int qsam_EOF;

qsam_EOF = 0; /* init EOF indicator */
buff = 0; /* init buff pointer */
/* Read records from the input and write to the output */
while(qsam_EOF == 0){
/* Get a Record from the input data set */
__asm(" LR 1,%1\n" /* Load the DCB address in Reg1 */
" LA 5,%2\n" /* put address of qsam_EOF in r5 */
" GET (1)\n" /* Issue GET macro */
" ST 1,%0" : /* Store buff ptr from reg1 */
"=m"(buff) : /* Output buffer return pointer */
"r"(in), /* Input DCB address */
"m"(qsam_EOF) : /* EOF indicator */
"r1","r5"); /* Regs 1,5 used */
readlen = in->dcblrecl; /* remember amount of data read */

/* Put that record to the output data set
* Since the Output DCB was defined as a Put Locate type,
* a pointer to an available buffer is returned in reg 1. Once
* PUT returns, we can then copy in the information to be
* written to the returned buffer for processing later. */
if (qsam_EOF == 0){
__asm(" LR 5,%1\n" /* Load the DCB address in Reg5 */
" PUT (5)\n" /* Issue PUT macro */
" ST 1,%0" : /* Store buff ptr from reg1 */
"=m"(outrec) : /* Output buffer return pointer */
"r"(out) : /* Input DCB address */
"r1","r5"); /* Regs 1,5,14,15 used */
/* Copy message into buffer */
outrec->qs_rdw = in->dcblrecl+1+4; /* msglen + asachar +
rdwsize */
outrec->qs_asa = kASALineFeed; /* ASA Line Feed char */
memcpy(&outrec->qs_buff, buff, in->dcblrecl);
bytes_written += readlen; /* increment # bytes */
}
};

return bytes_written;
}

/* Open a DCB for QSAM I/O
* Returns a pointer to a DCB area for the opened DD.
* Input: An 8 character, null terminated DD name string where the DD
* name is left-justified and padded on the right with blanks.
* A 1 character Open type - O for Output, I for Input
*/
/* Request that the compiler insert the default prolog
and epilog code to get and free autodata storage */
#pragma prolog(open_QSAM_dcb,"MYPROLOG")
#pragma epilog(open_QSAM_dcb,"MYEPILOG")

struct ihadcb* open_QSAM_dcb(char* ddname, char opentype){
struct ihadcb* dcbptr;
void* dcbe;

/* Check the parameters */
/* Check the parameters */
if (ddname == null ||
strlen(ddname) > 8 ||
(opentype != 'O' &&
opentype != 'o' &&
opentype != 'I' &&
opentype != 'i'))
return null;


/* Get 24 bit storage (backed anywhere in 64 bit) for the DCB. */
__asm(
" STORAGE OBTAIN,LENGTH=%1,"
"ADDR=%0,SP=131,LOC=(24,64),"
"KEY=8,BNDRY=DBLWD"
: "+m"(dcbptr) /* Output dcb pointer field */
: "i"(sizeof(struct ihadcb)+
sizeof(STDCBE)) /* Length to allocate */
);
dcbe = (void*)((void*)dcbptr)+sizeof(struct ihadcb);
/* clear newly obtained storage */
memset(dcbptr, 0, sizeof(struct ihadcb)+
sizeof(STDCBE));

/* Copy the DCB from static memory to storage */
switch(opentype){
case 'O':
case 'o':
memcpy(dcbptr,&stoutdcb,
sizeof(struct ihadcb));
break;
case 'I':
case 'i':
memcpy(dcbptr,&stindcb,
sizeof(struct ihadcb));
/* dcbptr->dcblrecl = 80; set 80 byte records. */
break;
default:
break;
}

/* copy in the static DCBE definition */
memcpy(dcbe,&STDCBE,kDCBElen);

/* Set other fields in DCB */
/* Set the DDNAME to be the requested DD name for this DCB */
memcpy(&dcbptr->dcbddnam, ddname, 8);
/* Replace the dummy DCBE pointer in the DCB */
dcbptr->dcbdcbe = dcbe;

/******************************************************************
* Open the DCB
******************************************************************/
/* Copy the DCB from static memory to storage */
switch (opentype){
case 'O':
case 'o':
/* define the OPEN parameter list in the dynamic
Autodata storage The long form of the parameter list
(MODE=31) is requested so that the module can be
AMODE 31. */
__asm(
" OPEN (,(OUTPUT)),MF=L,MODE=31" : "DS"(open_out_list));
/* Copy the static parameter list to dynamic stg */
open_out_list = open_output;

/* Open the output DD */
__asm(" OPEN ((%0)),MF=(E,(%1)),MODE=31" :
: "r"(dcbptr), "r"(&open_out_list));
break;
case 'I':
case 'i':
/* define the OPEN parameter list in the dynamic
Autodata storage The long form of the parameter list
(MODE=31) is requested so that the module can be
AMODE 31. */
__asm(
" OPEN (,(INPUT)),MF=L,MODE=31" : "DS"(open_in_list));
/* Copy the static parameter list to dynamic stg */
open_in_list = open_input;

/* Open the output DD */
__asm(" OPEN ((%0)),MF=(E,(%1)),MODE=31" :
: "r"(dcbptr), "r"(&open_in_list));
break;
default:
break;
}

/* Was the DD not Opened successfully? */
if (dcbptr->dcbofopn != 1)
{
/* Free the DCB storage */
__asm(
" STORAGE RELEASE,LENGTH=%1,KEY=8,"
"SP=131,ADDR=(%0)"
: /* No output fields */
: "r"(dcbptr), /* pointer to storage to free */
"i"(sizeof(struct ihadcb)) /* Length to free */
);
dcbptr = null; /* clear pointer */
}

return dcbptr; /* Return DCB pointer */
}

/* Close a non-VSAM data set.
* Input : DCB to be closed
* Output: Return code from CLOSE */
#pragma prolog(close_QSAM_dcb,"MYPROLOG")
#pragma epilog(close_QSAM_dcb,"MYEPILOG")

int close_QSAM_dcb(struct ihadcb* dcbptr){
int close_ret_code=0;

/* If the Output DD was Opened, then CLOSE it */
if (dcbptr->dcbofopn == 1){
/* The DCB was opened */
__asm(" CLOSE (),MF=L,MODE=31" : "DS"(close_list) );
close_list = close_static;
close_ret_code = 0;

/* CLOSE the DD */
__asm(" CLOSE ((%1)),MF=(E,(%2)),MODE=31\n"
" ST 15,%0" /* Store return code from reg15 */
: "=m"(close_ret_code) /* Output return code field */
: "r"(dcbptr), /* Input DCB pointer */
"r"(&close_list)); /* CLOSE parameter list */

} else
close_ret_code = 0; /* Return 0 if DCB was not open */

/* If the dcbptr is not null, free the storage */
if (dcbptr != null){
/* Free the DCB storage */
__asm(
" STORAGE RELEASE,LENGTH=%1,KEY=8,"
"SP=131,ADDR=(%0)"
: /* No output fields */
: "r"(dcbptr), /* Input pointer to free */
"i"(sizeof(struct ihadcb)) ); /* Length to free */
}
return close_ret_code;
}

/* The QSAMEOD function gets control when there is an End Of Data
event during a PUT/GET call using QSAM.
Before invoking GET, Register 5 is loaded with the address
of a field that indicates that End of File has been reached.
This code expects register 5 to contain the address of a 4 byte
field.
This function stores the value 1 into the field that register 5
points to as an indicator that End of File was reached. */
#pragma prolog(QSAMEOD,"MYPROLOG")
#pragma epilog(QSAMEOD,"MYEPILOG")
void QSAMEOD(void){
/* Remember that we hit End of File. */
__asm(" LA 2,1\n" /* put 1 into reg 2 */
" ST 2,0(,5)" /* store 1 into stg at r5 */
: : : "r2","r5"); /* regs 2,5 used */
}

/* The QSAMIOER function gets control when there is an I/O error
during a PUT/GET call using QSAM.
Before invoking PUT/GET, Register 5 should be loaded with the
address of a field that indicates that an I/O Error has occurred.
This code expects register 5 to contain the address of a 4 byte
field.
This function stores the value 2 into the field that register 5
points to as an indicator that I/O Error has occurred. */
#pragma prolog(QSAMIOER,"MYPROLOG")
#pragma epilog(QSAMIOER,"MYEPILOG")
void QSAMIOER(void){
/* Remember that we had an I/O Error. */
__asm(" LA 2,2\n" /* put 2 into reg 2 */
" ST 2,0(,5)" /* store 2 into storage at r5 */
: : : "r2","r5"); /* regs 2,5 used */
}


Joe
Post by ***@yahoo.com.au [H390-MVS]
Post by Joe Monk ***@gmail.com [H390-MVS]
On the mainframe, IBM has a version of C called
Metal C. This version uses standard OS linkage
conventions to call system functions. So, any
interface documented can be called just the same
as if you were calling from assembler.
That would only work for functions that are specified
as callable routines, not the many macros like OPEN
that are the normal interface to MVS facilities.
BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-10 02:50:23 UTC
Permalink
Post by Joe Monk ***@gmail.com [H390-MVS]
I would expect a metal 'C' routine using MVS
interfaces to look like this...
If you're prepared to put inline assembly into
your C code, I believe that works on non-METAL
too.

But I think a separate assembler routine like
I posted yesterday is neater than putting
that sort of stuff into the C code.

The C code in question is non-portable
anyway, so there's not much disadvantage
in breaking out the actual assembler.

BFN. Paul.
'M. Khalid Khan' khalidxyz@gmail.com [H390-MVS]
2018-02-09 22:29:08 UTC
Permalink
On Fri, 09 Feb 2018 01:47:32 -0600, ***@yahoo.com.au [H390-MVS]
<H390-***@yahoogroups.com> wrote:

<snip>
Post by ***@yahoo.com.au [H390-MVS]
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
The problem is that there is a lot of legacy code that was written
prior to C being wide spread. Arguing that it should be re-written
in C is silly.
I'm not. I'm countering people who say that
*even if* C had been available on exactly
the same day that S/370 assembler had
been invented, you should *still* write in
S/370 assembler because it is superior
to C in every way, and just as portable.
Just because something is available does not mean that everyone will adopt
it and use it exclusively. Not unless there is a world government
mandating and enforcing it and even then it will not be complete. At my
employer's we still use a lot of COBOL, some assembler and quite a bit of
Java. There may be some development in C but I'm not aware of it. And this
has been the case for most places I have worked for the last 30 years.
Post by ***@yahoo.com.au [H390-MVS]
It is right now that that attitude has hit a
gigantic brick wall as someone in the real
world has tried to port a body of code to
Unisys.
It's nothing more than a storm in a tea cup, if the user need it on Unisys
system they will pay for it. It's just cost of doing business.
Khalid
kerravon86@yahoo.com.au [H390-MVS]
2018-02-10 01:42:39 UTC
Permalink
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
The problem is that there is a lot of legacy code that was written
prior to C being wide spread. Arguing that it should be re-written
in C is silly.
I'm not. I'm countering people who say that
*even if* C had been available on exactly
the same day that S/370 assembler had
been invented, you should *still* write in
S/370 assembler because it is superior
to C in every way, and just as portable.
Just because something is available does
not mean that everyone will adopt
it and use it exclusively.
But I didn't claim anything of the sort. What I
claimed was that with the advent of C, you can
now write low-level programs in a combination
of C and S/370 assembler, instead of pure
S/370 assembler, and that allows a portion of
your application to be portable.

The people you should have an issue with are
the people who say that even if C were available,
it should never be used, because S/370 is just
as portable as C.
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
It is right now that that attitude has hit a
gigantic brick wall as someone in the real
world has tried to port a body of code to
Unisys.
It's nothing more than a storm in a tea cup, if the user need it on Unisys
system they will pay for it. It's just cost of doing business.
Yes, a HIGHER cost of doing business because
S/370 was used instead of C.

Higher costs are passed on to the consumer, so
the whole world loses.

BFN. Paul.
'M. Khalid Khan' khalidxyz@gmail.com [H390-MVS]
2018-02-10 05:27:00 UTC
Permalink
Post by ***@yahoo.com.au [H390-MVS]
But I didn't claim anything of the sort. What I
claimed was that with the advent of C, you can
now write low-level programs in a combination
of C and S/370 assembler, instead of pure
S/370 assembler, and that allows a portion of
your application to be portable.
Portability may not be so important to some as it is to you. Unless
someone is forcing you to write assembler against your wishes there is no
reason to get fired up like that.
Post by ***@yahoo.com.au [H390-MVS]
The people you should have an issue with are
the people who say that even if C were available,
it should never be used, because S/370 is just
as portable as C.
I don't have a problem with anyone using a language of their choice. I
would definitely have issue with people trying to tell me what to do but
no one has done so here. You with your strong and repeated advocacy of C
tend to go in that direction.
Post by ***@yahoo.com.au [H390-MVS]
Yes, a HIGHER cost of doing business because
S/370 was used instead of C.
Higher costs are passed on to the consumer, so
the whole world loses.
In order to achieve these lower costs they would have to invest in future
revealing technologies which would have told them way back when that in
2018 they will need to move this code to a Unisys machine so they should
write it in C. Was the code written before C was available or after ? Also
what would have been the cost of this future reading technology ? Lots of
questions, no clear cut answers.

Khalid


------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
kerravon86@yahoo.com.au [H390-MVS]
2018-02-10 05:53:26 UTC
Permalink
Post by 'M. Khalid Khan' ***@gmail.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
Yes, a HIGHER cost of doing business because
S/370 was used instead of C.
Higher costs are passed on to the consumer, so
the whole world loses.
In order to achieve these lower costs they would have to invest in future
revealing technologies which would have told them way back when that in
2018 they will need to move this code to a Unisys machine so they should
write it in C. Was the code written before C was available or after ? Also
what would have been the cost of this future reading technology ? Lots of
questions, no clear cut answers.
This is not the point I am making.

The point I am making is that *with the benefit
of hindsight* and *with the availability of the
C language*, this *particular code* would
*probably* have been better written in C, or
a mix of C and S/370 assembler, rather than
insisting that S/370 assembler beats the pants
off C in all cases and S/370 is just as portable
as C anyway.

Of course I am aware that it is impossible to
go back in time.

My message is to people who insist that *even
with the benefit of hindsight*, C would never
have had a place on the S/370 architecture,
because S/370 assembler did everything
that C could do, with no downside whatsoever.

Quite apart from the productivity question, which
depends on the individual, there was always a
downside waiting for any body of code that
would end up being used on another
environment - the lack of portability and the
need for a complete rewrite.

The theory that S/370 assembler is equally as
portable as C, ie "just use z390" or some other
bizarre solution, is just nonsense.

BFN. Paul.
Guy Sotomayor Jr ggs@shiresoft.com [H390-MVS]
2018-02-09 21:15:24 UTC
Permalink
It seems obvious to me that you’re a “fan-boy” of C.. I don’t actually know how
long or what environments you’ve written C (or what other environments/languages
you’ve written in) but I get a little skeptical when someone is suggesting using C for all
problems.

Even though I predominately write code in C, I still end up writing a fair amount of
code in assembler (for what ever platform I’m working on) in addition to other languages,
it depends upon the problem domain I’m working in. I choose the language that is most
applicable to the problem I’m trying to solve: C, Fortran, Forth, Lisp are my “go to”
languages but I’ve written in some other esoteric languages if they are a better fit to
the problem at hand.

It also appears that your assertion is that just by writing in C you get portability. It is
simply not true. I’ve tried to point out a few of the pitfalls (not to mention the language
limitations) but have been ignored. A lot of portability issues do not show up until you
want to represent data external to the program. That is when you hit a lot of issues.

That’s OK, each one of us has our own options. I’m just trying to share some of my
40+ years of dealing with C and writing many 100,000’s of lines of C code as well as
porting even more C code between various platforms.

TTFN - Guy
Post by ***@yahoo.com.au [H390-MVS]
I’m taking issue with some of the statement that C is portable...
It is up to a point. Without seeing the code and the destination
platform, I would not assert anything in terms of portability for
C, certainly not in the 99% range.
It depends if you are using C for some low-level
work or for application logic.
If you are using it for application logic, it is in
the 99% range, unlike S/370 assembler which
is in the 0% range.
GCC and IFOX are almost completely application
logic, so literally hundreds of thousands of lines
of code pass through without problem.
Post by ***@yahoo.com.au [H390-MVS]
At the point you decide to throw out C and write
in S/370 assembler, the size of an int is exactly
32 bits exactly guaranteed. This assumption
will only bite you when you try to port the code
to a 16-bit micro, not when you try to port to
Unisys.
I understand that the target of this thread has been porting from
S/370 to Unisys but given the general notion of portability (which
you’ve been asserting), you can’t make the assumption of the
size of an int (it could be 16, 32, 64, or what ever).
What you are saying is technically correct.
That doesn't alter the fact that what I said was
technically correct also. At the point you are
thinking of writing in S/370 assembler, where
the size of R2 is exactly 32 bits, C will rise to
that challenge. int is exactly 32 bits too.
Again, that assumption won't bite you in the
bum if you port to Windows, Unix, or MVS.
Or Unisys in this case.
Writing in S/370 assembler will bite you in
the bum from the fist line of code you write,
because you get to rewrite it all again when
it's time to port to Unisys. ALL of it. AGAIN.
You may as well just do it once in C and
watch the beautiful S/370 assembler get
generated, with an infinite number of registers
and infinite addressability.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Order of bits in a bit-field is completely up to the
compiler.
Not sure why that should be an issue when
porting to Unisys.
Because the ordering of the bits is *completely* up to the
compiler. So if you go from S/370 to Unisys, that is presumably
a different compiler, so there’s no guarantee that the bit order
on S/370 will be the same as on Unisys.
I'm lost. Why should you care what the bit order
is on Unisys? And again, C is not being compared
in a vacuum, it is being directly compared to
S/370 assembler. If you use bitfields in S/370
assembler they are set in a fixed order too.
Hell, different
compilers on the same platform can order bit fields differently
(I’ve seen it, which is why I *never* use bit fields
same goes
for enums).
They both work fine.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Frankly, the language definition itself has lots of
issues that simple typographical mistakes can
lead to difficult to diagnose bugs (e.g. mis-typing
= for == in a comparison).
A good compiler will give you a warning about
that, and regardless, the competition is with
S/370 assembler, not some theoretically perfect
language. In S/370 you run out of both registers
and addressability, which sucks.
No, a compiler will not give you a warning because both
(a) if (a=b) { foo }
(b) if (a==b) { foo }
That's precisely why you get a WARNING not
an ERROR. If I show you a good compiler that
generates a warning for (a) above but not (b)
below, will you admit you are wrong?
If you meant to have (b) the compiler can’t say anything
if you wrote (a) because (a) is completely valid C syntax.
If you believe C syntax has deficiencies, so
be it, that's in the eye of the beholder. It
doesn't take away anything from C being
portable, especially when faced with the
real world challenge of taking a body of
code from MVS to Unisys. C beats the
pants off S/370 assembler completely and
utterly.
All I’m saying is that C is far from a perfect language and
I never claimed C was a perfect language.
Only that you should think 1000 times before
you write something in S/370 assembler and
think about writing it in C instead.
the above illustrates it. Having two completely different
(and undetectable) behaviors for a type-o.
It is detectable, but even if it wasn't, typos in
S/370 assembler aren't detectable either.
It was a mistake to have the assignment operator (=)
differ from the equality operator. Other languages at the
time made assignment something like “:=“ and equality
either “=“ or “==“.
Maybe. Maybe not. It's a hell of lot easier to
get those things right than it is to get
S/370 assembler right. I'm probably 30 times
more productive in C than assembler, and
more to the point, C programmers are a dime
a dozen.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
That's even leaving
off the potential issue of endianness.
That exists with S/370 assembler too.
Why? In C I don’t know if the representation of a
value is big or little endian and without resorting to
“tricks” code can’t know and can get into trouble by
making assumptions about endian.
Which bit about "that exists with S/370 assembler
too" do you disagree with?
That’s because GCC has been around for a relatively long
period of time and has been ported to a number of different
platforms, so I’m not surprised.
So you're not surprised that it is possible
to write 400,000 lines of totally portable
C code if you do it properly?
Thanks. That concludes the case for the
affirmative.
Actually at this point GCC is a pretty antiquated C compiler.
CLANG and LLVM are *much* superior compiler implementations.
Do they have S/370 targets so that they can
run on standard Hercules S/370?
The problem with the standard is that it still leaves large “holes”
of either platform or compiler dependent behavior. That *is*
the reason why portability of C is hard
too much of what needs
to be done falls into the grey areas.
Again, 400,000 lines of code can't be wrong.
As one of my colleagues said many years ago, all C compilers
will accept correct C programs. It is the set of incorrect C programs
that they accept is the source of many portability issues. Said
another way, until I’ve run my code through a number of different
C compilers, I don’t actually know if my code actually conforms to
the standard (and then I’m not 100% sure). gcc (even with the
latest compilers at C99 checking level) accepts a lot of code that
isn’t compliant (to the standard) C code.
Yes, so case in point, you may have to fix 3
bugs when you port the C code from S/370
to Unisys. I'd much rather be in a position of
hiring a Unisys C programmer to fix 3 bugs
than hire a Unisys C programmer to rewrite
an entire body of code in S/370 assembler
(which they don't even know) into C.
Even if you know in advance that when writing
in C on S/370 that you are going to write 3
undetectable bugs, you should STILL write in
C instead of S/370 assembler.
The problem is that there is a lot of legacy code that was written
prior to C being wide spread. Arguing that it should be re-written
in C is silly.
I'm not. I'm countering people who say that
*even if* C had been available on exactly
the same day that S/370 assembler had
been invented, you should *still* write in
S/370 assembler because it is superior
to C in every way, and just as portable.
It is right now that that attitude has hit a
gigantic brick wall as someone in the real
world has tried to port a body of code to
Unisys.
I can’t speak for S/370 as I’ve never written in C for it. But for
the platforms I work on (x86, ARM, PPC, etc) I don’t have a
problem reading (and debugging) the output assembler even
at high optimization levels.
Well IBM C is in a class of its own then, with
experienced assembler programmers switching
off optimization to produce assembler code that
is as simple as they would have written
themselves.
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
C also has a very simple memory model (some
might say it's a strength) which makes it difficult
to use more interesting memory models (and if
you do, there goes *any* hope of portability).
We're not talking about "more interesting memory
models", we're talking about S/370.
I’m talking about portability of C in general.
And I'm talking about real world usage, of some
poor guy tasked with porting code from MVS
to Unisys, not some theoretically pure language
that beats the pants off C.
The competition is between C and S/370
assembler in this case, and in my opinion, C
beats the pants off S/370 assembler.
size_t doesn’t solve the memory model issue.
The perhaps you could explain the "issue".
You’ve obviously never written C code for 8086 or 80286
(or segmented 80386/80486).
On the contrary, I've not just written code for
8086 and 80386, I've written a friggin ENTIRE
C RUNTIME LIBRARY for BOTH of those,
combined with an ENTIRE OPERATING SYSTEM
for BOTH of those. PDOS/86 and PDOS/386
and PDPCLIB, all available, free and genuine
http://pdos.sourceforge.net <http://pdos.sourceforge.net/>
Post by ***@yahoo.com.au [H390-MVS]
It’s *ugly* code. Am I dealing
with a small memory model, a large memory model or a
huge memory model?
You don't need to know. Whatever the application
is that you are trying to write, such as hexdump
or some file transfer application as is the problem
at hand, you just need to follow the rules and
you don't need to care about large etc. You just
rebuild your application in whichever memory
model is most suitable, for whichever processor
is most suitable.
Different memory models break the assumption of
sizeof(void *) == sizeof(int) which a lot of code makes.
You have isolated a problem with some lousy
C programmers. Note that the people who
wrote the 400,000 lines of GCC haven't made
that assumption. This has nothing to do with
C not being portable, and nothing to do with
the specific case at hand of going from S/370
to Unisys.
In addition, it is actually C's strength compared
to all other languages that when you have
pointers, such as your "void *" above, you
should never be in a position of interchanging
pointers and integers, as these things are
kept separate with things like size_t and
pointer incrementing that is done in terms of
what the pointer is pointing to rather than
some integer amount.
It's a beauty to behold.
And again, beats the pants off writing it once
in S/370 assembler and then rewriting it in C
when it's time to move to Unisys.
Having used a lot of different languages, I can say that C
is a very low level systems implementation language. For
things that don’t need to be at that level, I prefer to use a
higher level language that doesn’t suffer from the portability
issues of C.
I don't have a problem with that either. I don't
have a problem with people writing business
applications in Cobol either. What I have an
issue with is people writing application logic
(ie loops) in S/370 assembler when they
should be using C, which has a very good
chance of being ported to other platforms
such as Unisys as a real-world example.
One of the reasons that C became so widespread was the
fact that there (originally) was a reference compiler (PCC)
*and* that the C runtime was fairly simple, so getting a new
compiler going on a new platform/environment was relatively
simple.
Sounds good to me. And now we have exactly
that with GCCMVS. 400,000 lines of C code
now running natively on S/370.
BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-10 01:38:07 UTC
Permalink
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
That’s OK, each one of us has our own options. I’m just trying to share some of my
40+ years of dealing with C and writing many 100,000’s of lines of C code as well as
porting even more C code between various platforms.
And I have shared my 30 years of dealing in C,
not just porting C between diverse platforms
like MVS and Windows, but also writing a C
runtime library, mostly in C, for numerous
environments including MSDOS, Windows,
OS/2, Unix, MVS, CMS, DOS/VS, and also
writing an MSDOS-like operating system not
just for the 8086, but also 80386 and S/370
and S/390, also mostly in C across all
environments.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
It seems obvious to me that you’re a “fan-boy” of C. I don’t actually know how
long or what environments you’ve written C (or what other environments/languages
you’ve written in) but I get a little skeptical when someone is suggesting using C for all
problems.
That is a misrepresentation of what I said. I specifically
said I had no problem with people writing business
applications in C.

I specifically said that what I had a problem with was
people saying that S/370 is just as portable as C so
you may as well just write in S/370.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Even though I predominately write code in C, I still end up writing a fair amount of
code in assembler (for what ever platform I’m working on) in addition to other languages,
it depends upon the problem domain I’m working in.
Yes, and so do I. I do low-level work too. The
distinction is whether it is possible to write a
portion of the code in portable C and the other
bit in totally unportable S/370 assembler.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
I choose the language that is most
applicable to the problem I’m trying to solve: C, Fortran, Forth, Lisp are my “go to”
languages but I’ve written in some other esoteric languages if they are a better fit to
the problem at hand.
And you will find that C is the one most likely
to actually work across the different environments,
and is the one that actually implements pointers
properly, as required for low-level work.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
It also appears that your assertion is that just by writing in C you get portability. It is
simply not true. I’ve tried to point out a few of the pitfalls (not to mention the language
limitations) but have been ignored.
No, you ignored what I pointed out - that the C90
standard is in fact portable, and you can process
hundreds of thousands of lines of code through
it on both Windows and MVS, and you can't judge
the language by the fact that some people don't
write standard code.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
A lot of portability issues do not show up until you
want to represent data external to the program.
That is when you hit a lot of issues.
If your data needs to be a specific format when
you present it externally you must code it that
way in order for your code to be portable. If a
lazy C programmer just assumes that the
external and internal formats match, that is a
direct violation of the C90 standard and not
a sign that there is something wrong with the
language itself.

BFN. Paul.
Guy Sotomayor Jr ggs@shiresoft.com [H390-MVS]
2018-02-10 03:19:28 UTC
Permalink
My point (and it keeps getting ignored) is that the C standard in and of itself
does *not* ensure portability because of many parts of the standard are
“left to the compiler” or environment to define.

For example, if you want portability you cannot use char, int, etc because
the size is not defined. You need to use typedefs such as uint16_t, uint32_t, etc.
And that’s just to deal with sizes of fundamental types. There are *many*
other aspects that impact portability that are *not* covered by the C
standard. That is why there are supplemental standards (such as MISRA
which I referenced previously) to make up for the portability shortcomings
of the C standard.

TTFN - Guy
Post by ***@yahoo.com.au [H390-MVS]
That’s OK, each one of us has our own options. I’m just trying to share some of my
40+ years of dealing with C and writing many 100,000’s of lines of C code as well as
porting even more C code between various platforms.
And I have shared my 30 years of dealing in C,
not just porting C between diverse platforms
like MVS and Windows, but also writing a C
runtime library, mostly in C, for numerous
environments including MSDOS, Windows,
OS/2, Unix, MVS, CMS, DOS/VS, and also
writing an MSDOS-like operating system not
just for the 8086, but also 80386 and S/370
and S/390, also mostly in C across all
environments.
It seems obvious to me that you’re a “fan-boy” of C. I don’t actually know how
long or what environments you’ve written C (or what other environments/languages
you’ve written in) but I get a little skeptical when someone is suggesting using C for all
problems.
That is a misrepresentation of what I said. I specifically
said I had no problem with people writing business
applications in C.
I specifically said that what I had a problem with was
people saying that S/370 is just as portable as C so
you may as well just write in S/370.
Even though I predominately write code in C, I still end up writing a fair amount of
code in assembler (for what ever platform I’m working on) in addition to other languages,
it depends upon the problem domain I’m working in.
Yes, and so do I. I do low-level work too. The
distinction is whether it is possible to write a
portion of the code in portable C and the other
bit in totally unportable S/370 assembler.
I choose the language that is most
applicable to the problem I’m trying to solve: C, Fortran, Forth, Lisp are my “go to”
languages but I’ve written in some other esoteric languages if they are a better fit to
the problem at hand.
And you will find that C is the one most likely
to actually work across the different environments,
and is the one that actually implements pointers
properly, as required for low-level work.
It also appears that your assertion is that just by writing in C you get portability. It is
simply not true. I’ve tried to point out a few of the pitfalls (not to mention the language
limitations) but have been ignored.
No, you ignored what I pointed out - that the C90
standard is in fact portable, and you can process
hundreds of thousands of lines of code through
it on both Windows and MVS, and you can't judge
the language by the fact that some people don't
write standard code.
A lot of portability issues do not show up until you
want to represent data external to the program.
That is when you hit a lot of issues.
If your data needs to be a specific format when
you present it externally you must code it that
way in order for your code to be portable. If a
lazy C programmer just assumes that the
external and internal formats match, that is a
direct violation of the C90 standard and not
a sign that there is something wrong with the
language itself.
BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-10 03:30:48 UTC
Permalink
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
My point (and it keeps getting ignored)
is that the C standard in and of itself does
*not* ensure portability because of many
parts of the standard are
“left to the compiler” or environment to define.
No-one said it *ensured* portability.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
For example, if you want portability you cannot use char, int, etc because
the size is not defined. You need to use typedefs such as uint16_t, uint32_t, etc.
This is simply not true. You are free and
encouraged to use char, int etc. They are
specified to have a *minimum* size. You
cannot assume that you will get some
sort of maximum number of bits at which
you can assume bits will start getting
truncated. E.g. you might be on a machine
with 36-bit ints, and no integer type with
exactly 32 bits.

Similarly code on z/Arch can't rely on
addresses being truncated at exactly 31
bits, because when running AM64 that
no longer happens.

And again, how many times do I need to
repeat it, the portability of C is not being
compared in a vacuum, it's being compared
to the real world situation of S/370 being the
alternative, and then needing to port to
Unisys later.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
And that’s just to deal with sizes of fundamental types. There are *many*
other aspects that impact portability that are *not* covered by the C
standard.
I never claimed every possible program could
be written in portable C.

What I claim, and you keep ignoring again and
again, is that in the real world, C gives you a
chance of porting *some* of your code, while
coding in S/370 assembler locks out all
possibility absolutely totally 100%.

BFN. Paul.
Joe Monk joemonk64@gmail.com [H390-MVS]
2018-02-10 13:04:14 UTC
Permalink
"The easiest way to write portable code is not to use C. If portable code
is your most important design goal, choose a language that provides a much
more abstract model of a computer and shields you from all of the details
of the architecture."

http://www.informit.com/articles/article.aspx?p=1620206&seqNum=1

Joe
Post by ***@yahoo.com.au [H390-MVS]
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
My point (and it keeps getting ignored)
is that the C standard in and of itself does
*not* ensure portability because of many
parts of the standard are
“left to the compiler” or environment to define.
No-one said it *ensured* portability.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
For example, if you want portability you cannot use char, int, etc
because
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
the size is not defined. You need to use typedefs such as uint16_t,
uint32_t, etc.
This is simply not true. You are free and
encouraged to use char, int etc. They are
specified to have a *minimum* size. You
cannot assume that you will get some
sort of maximum number of bits at which
you can assume bits will start getting
truncated. E.g. you might be on a machine
with 36-bit ints, and no integer type with
exactly 32 bits.
Similarly code on z/Arch can't rely on
addresses being truncated at exactly 31
bits, because when running AM64 that
no longer happens.
And again, how many times do I need to
repeat it, the portability of C is not being
compared in a vacuum, it's being compared
to the real world situation of S/370 being the
alternative, and then needing to port to
Unisys later.
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
And that’s just to deal with sizes of fundamental types. There are *many*
other aspects that impact portability that are *not* covered by the C
standard.
I never claimed every possible program could
be written in portable C.
What I claim, and you keep ignoring again and
again, is that in the real world, C gives you a
chance of porting *some* of your code, while
coding in S/370 assembler locks out all
possibility absolutely totally 100%.
BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-10 13:31:12 UTC
Permalink
Post by Joe Monk ***@gmail.com [H390-MVS]
The easiest way to write portable code is not
to use C. If portable code is your most important
design goal, choose a language that provides a
much more abstract model of a computer and
shields you from all of the details of the architecture.
If you believe there is a language, perhaps COBOL
METAL, that exists on both MVS and Unisys, that
provides an adequate replacement for S/370
assembler, which is what is competing against, ie
someone is seriously thinking about writing in
S/370 assembler code (knowing that it will need
to be rewritten in some other language at the
point that it gets ported to Unisys), code that could
otherwise be written in C - go for it!

I know of no such thing as COBOL METAL. I only
know of METAL C. Or you can use GCCMVS if
you don't have that paid product.

I read the article you attached and don't see any
issue with using C that doesn't also exist in a
much much worse manner with S/370 assembler.

BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-11 03:33:00 UTC
Permalink
Post by ***@yahoo.com.au [H390-MVS]
If you believe there is a language, perhaps COBOL
METAL, that exists on both MVS and Unisys, that
Or perhaps METAL BASIC, given that BASIC was
previously touted as the universal language for
computers, supplanting C.

Note that on our free MVS 3.8j, the only BASIC
being used is bwbasic which is written in terms
of the REAL universal language - C. Good luck
writing a file transfer program in BASIC.

BFN. Paul.
'Bill Turner, WB4ALM' wb4alm@arrl.net [H390-MVS]
2018-02-09 12:36:31 UTC
Permalink
with regards to "=" meaning both "assignment" and "compare equal" you
can blame the ASCII coding committee way back in the "before 1964" time era.

Most members of the committee wanted to keep the "left pointing arrow" 
but the linguistic folks on the committee keep arguing that they had to
have the "caret" instead.
The arguement was that "n backspace colon"   and   "n  backspace caret"
and  "n backspace quotation mark"  and ...  was very important to
foreign languages.
Rumor was that the "final approval" would not occur unless their final
demand was meet.

So the "left arrow" was replaced by the "caret".
(politics, politics, politics...)

I just love the fact that just a few years later, the modern "terminal"
(ie CRT), does not allow for overlaying character graphics!
And then the industry came up with a better standard for foreign
language graphics, like "UTF" and ...


Many higher level languages in the 1964 - 1968 time frame allowed "A ← B
+ C"; and it would have been nice to have been able to kept it that way...

It also amazes me that many modern languages have no problem telling the
difference between "=" being used as an assignment operator and "="
being used as a comparison operator, and "==" is commonly  used as an
"exactly equal comparison operator".

Many, that is, except for "C" and some later languages (like PHP) that
were created by folks that apparently only "knew"  C  ...

/s/ Bill Turner, wb4alm
Post by Guy Sotomayor Jr ***@shiresoft.com [H390-MVS]
Post by ***@yahoo.com.au [H390-MVS]
Post by ***@shiresoft.com [H390-MVS]
Frankly, the language definition itself has lots of
issues that simple typographical mistakes can
lead to difficult to diagnose bugs (e.g. mis-typing
= for == in a comparison).
A good compiler will give you a warning about
that, and regardless, the competition is with
S/370 assembler, not some theoretically perfect
language. In S/370 you run out of both registers
and addressability, which sucks.
No, a compiler will not give you a warning because both
(a)    if (a=b) { foo }
(b)    if (a==b) { foo }
If you meant to have (b) the compiler can’t say anything
if you wrote (a) because (a) is completely valid C syntax.
All I’m saying is that C is far from a perfect language and
the above illustrates it.  Having two completely different
(and undetectable) behaviors for a type-o.
It was a mistake to have the assignment operator (=)
differ from the equality operator.  Other languages at the
time made assignment something like “:=“ and equality
either “=“ or “==“.
C did fix a few things early on.  Increment/decrement
used to be =+ and =- vs += and -= as they are now and
they were fixed in the v6->v7 transition.  It was pointed
out that = vs == was equally an issue but K&R decided
not to change it.
João Reginato jb.reginato@gmail.com [H390-MVS]
2018-02-08 12:57:54 UTC
Permalink
I would like to thank each one of you who answered this warm question.

Unfortunately I don't have familiarity with C as I have with Assembler and Cobol, otherwise I would write it in portable C of course. The time has come to learn. It is never too late. Now I can see how inocent my question was



João





De: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Enviada em: quinta-feira, 8 de fevereiro de 2018 02:46
Para: H390-***@yahoogroups.com
Assunto: Re: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion





C is available either as standard, or for free,
on all commercially-used platforms, as far
as I know.

And I sure wish you would understand that
I'm advocating using C for anything on MVS
that you would otherwise write in 370
assembler, if you may ever be in a situation
where you need to port to Unisys. As is the
case now. Write it once. Write it in C.

BFN. Paul.

---In H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> , <***@.... <mailto:***@...> > wrote :

When 90% of your production programs are written in COBOL, and when you have to consider the cost of 100's of copies of leased software (one for each mainframe image) you better beleive you CAN NOT cost justify buying new compiliers for languages that aren't going to be used very often.

Sure wish you would get your head out of the sand with this belief that --ONLY-- "C" should be used for anything...

/s/ Bill Turner, wb4alm


On 02/07/2018 09:59 PM, ***@... mailto:***@... [H390-MVS] wrote:



@joe - shops that do not have a C compiler
in 2017 are doing so by choice, not because
they can't cost-justify buying a C compiler.

BFN. Paul.
kerravon86@yahoo.com.au [H390-MVS]
2018-02-08 14:33:15 UTC
Permalink
If you would like assistance learning C using
MVS as the development platform, I am happy
to assist you for free via email. I did this a year
or so ago with someone else and he was very
happy with the result. You can ask the most
basic questions you want, or you can say "I
can do xyz in S/370 assembler, how do I do
it in C?" and I will be able to answer you.

Or you can post your questions in hercules-os380
if you would like others to be able to assist you
as well.

I'm actually planning on writing a computer course
for people to follow that teaches BASIC on the PC,
followed by a little bit of C on the PC, followed by
C on MVS, followed by S/370 assembler on MVS
to stop MVS and EBCDIC being left out in the cold
as a freeware target. I've already got the BASIC on
PC part written and you can see it here:

http://mutazilah.org/learnp.txt

I haven't yet considered how to transition people
to MVS, and I'm still seeing how successful I am
with the above BASIC tutorial (I've got one person
doing it currently, so far so good).

I think that MVS, including C and assembler,
will provide a good bulwark for anyone embarking
on programming on some other platform in any
language.

BFN. Paul.




---In H390-***@yahoogroups.com, <***@...> wrote :

I would like to thank each one of you who answered this warm question.
Unfortunately I don't have familiarity with C as I have with Assembler and Cobol, otherwise I would write it in portable C of course. The time has come to learn. It is never too late. Now I can see how inocent my question was

João


De: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Enviada em: quinta-feira, 8 de fevereiro de 2018 02:46
Para: H390-***@yahoogroups.com
Assunto: Re: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion




C is available either as standard, or for free,
on all commercially-used platforms, as far
as I know.

And I sure wish you would understand that
I'm advocating using C for anything on MVS
that you would otherwise write in 370
assembler, if you may ever be in a situation
where you need to port to Unisys. As is the
case now. Write it once. Write it in C.

BFN. Paul.

---In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com, <***@... mailto:***@...> wrote :

When 90% of your production programs are written in COBOL, and when you have to consider the cost of 100's of copies of leased software (one for each mainframe image) you better beleive you CAN NOT cost justify buying new compiliers for languages that aren't going to be used very often.

Sure wish you would get your head out of the sand with this belief that --ONLY-- "C" should be used for anything...

/s/ Bill Turner, wb4alm



On 02/07/2018 09:59 PM, ***@... mailto:kerravon86@ mailto:***@... [H390-MVS] wrote:



@joe - shops that do not have a C compiler
in 2017 are doing so by choice, not because
they can't cost-justify buying a C compiler.

BFN. Paul.
João Reginato jb.reginato@gmail.com [H390-MVS]
2018-02-08 17:45:58 UTC
Permalink
Thank you Paul. I’ll do that ASAP





De: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Enviada em: quinta-feira, 8 de fevereiro de 2018 11:33
Para: H390-***@yahoogroups.com
Assunto: Re: [H390-MVS] Re: Unysis conversion





If you would like assistance learning C using
MVS as the development platform, I am happy
to assist you for free via email. I did this a year
or so ago with someone else and he was very
happy with the result. You can ask the most
basic questions you want, or you can say "I
can do xyz in S/370 assembler, how do I do
it in C?" and I will be able to answer you.

Or you can post your questions in hercules-os380
if you would like others to be able to assist you
as well.

I'm actually planning on writing a computer course
for people to follow that teaches BASIC on the PC,
followed by a little bit of C on the PC, followed by
C on MVS, followed by S/370 assembler on MVS
to stop MVS and EBCDIC being left out in the cold
as a freeware target. I've already got the BASIC on
PC part written and you can see it here:

http://mutazilah.org/learnp.txt

I haven't yet considered how to transition people
to MVS, and I'm still seeing how successful I am
with the above BASIC tutorial (I've got one person
doing it currently, so far so good).

I think that MVS, including C and assembler,
will provide a good bulwark for anyone embarking
on programming on some other platform in any
language.

BFN. Paul.

---In H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> , <***@... <mailto:***@...> > wrote :

I would like to thank each one of you who answered this warm question.
Unfortunately I don't have familiarity with C as I have with Assembler and Cobol, otherwise I would write it in portable C of course. The time has come to learn. It is never too late. Now I can see how inocent my question was

João


De: H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> [mailto:H390-***@yahoogroups.com]
Enviada em: quinta-feira, 8 de fevereiro de 2018 02:46
Para: H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com>
Assunto: Re: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion

C is available either as standard, or for free,
on all commercially-used platforms, as far
as I know.

And I sure wish you would understand that
I'm advocating using C for anything on MVS
that you would otherwise write in 370
assembler, if you may ever be in a situation
where you need to port to Unisys. As is the
case now. Write it once. Write it in C.

BFN. Paul.

---In H390-***@yahoogroups.com <mailto:H390-***@yahoogroups.com> mailto:H390-***@yahoogroups.com, <***@.... mailto:***@... <mailto:***@....%20mailto:***@...> > wrote :

When 90% of your production programs are written in COBOL, and when you have to consider the cost of 100's of copies of leased software (one for each mainframe image) you better beleive you CAN NOT cost justify buying new compiliers for languages that aren't going to be used very often.

Sure wish you would get your head out of the sand with this belief that --ONLY-- "C" should be used for anything...

/s/ Bill Turner, wb4alm

On 02/07/2018 09:59 PM, ***@... mailto:kerravon86@ mailto:***@... [H390-MVS] wrote:

@joe - shops that do not have a C compiler
in 2017 are doing so by choice, not because
they can't cost-justify buying a C compiler.

BFN. Paul.
Loading...