Re: C/C++ Runtime Library

[Jeremy Nicoll]

On Wed, 8 Nov 2017, at 22:48, Paul Gilmartin wrote:

> "P-Code" sounds like jargon from UCSD Pascal, which I brushed 
> against 30+  years ago.  There was no pass two; there was an 
> interpreter for the P-Code.

I've always associated P-code with Wirth's Pascal compiler.   But it 
turns out that the term is more general than that, and even for 
Pascal is relevant to several early compilers.  See: 

  https://en.wikipedia.org/wiki/P-code_machine


-- 
Jeremy Nicoll - my opinions are my own.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[Paul Gilmartin]

On Wed, 8 Nov 2017 23:20:41 +0100, Bernd Oppolzer wrote:
>
>Just to give an example, how small a runtime library can be:
>
>my New Stanford Pascal compiler has a runtime library, which is also linked 
>with every
>Pascal program (in the same way as Dave describes). The Pascal compiler itself 
>is
>a Pascal program (ca. 15.000 lines at the moment - pass one, generating 
>P-Code; the
>P-Code is later translated to 370 machine code, which is done in pass two, 
>which has
>another 12000 lines). For the following discussion, PASCAL1 (pass one) only 
>serves as
>an example of a (large) Pascal program.
>
"P-Code" sounds like jargon from UCSD Pascal, which I brushed against 30+ years 
ago.
There was no pass two; there was an interpreter for the P-Code.

(In other jargon) The runtime library was a single large load module which was
linked with every program.  But there was a "smart linker" which filtered that 
large
object and deleted every unreferenced CSECT, making the executable as small as
possible.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[Bernd Oppolzer]

Am 08.11.2017 um 18:47 schrieb Thomas David Rivers:

Frank Swarbrick wrote:


Doesn't that make for fairly large executables?




Well - it can - but a trimmed down C library is surprisingly small.

Of course - if you're dragging C++ into this, then things get bigger; but
again - that's not the library usually, it's the templates, etc.. that 
your

program instantiates...

It seems, in practice, to not be an issue at all.

 - Dave Rivers -



Just to give an example, how small a runtime library can be:

my New Stanford Pascal compiler has a runtime library, which is also 
linked with every
Pascal program (in the same way as Dave describes). The Pascal compiler 
itself is
a Pascal program (ca. 15.000 lines at the moment - pass one, generating 
P-Code; the
P-Code is later translated to 370 machine code, which is done in pass 
two, which has
another 12000 lines). For the following discussion, PASCAL1 (pass one) 
only serves as

an example of a (large) Pascal program.

Pass one has, after compilation, the following size:

 ENTRY ADDRESS    1E940
 TOTAL LENGTH 30AC8
PASCAL1   NOW REPLACED IN DATA SET
AUTHORIZATION CODE IS 0.

the size of PASCAL1 is 200 k, ca.

Excerpts from the Linker listing:

  CONTROL SECTION   ENTRY
    NAME    ORIGIN  LENGTH    NAME   LOCATION NAME   LOCATION
  $PASMAI#  00 E28
  $PRV0001 E28  AC
  $PRV0002 ED8  C8
  $PRV0003 FA0  E8
  $PRV0004    1088  78

The runtime starts here:

  $PASENT    1E940    53E0
    $PASINT    1EE88 $PASTRC    1F0CC
    IHNERRM    1FB36 ERRMON 1FB36
    IHCERRE    1FB6A $PASSYS    1FB78
    $PASCSP2   2005A
  $PASLIB#   23D20  2C
  $LIBX002   23D50  BC
  $LIBX004   23E10 118

that is:

the "core" runtime, written in ASSEMBLER, is $PASENT,
and its size is 21 k (!).

The "library" functions from $PASLIB (written in Pascal)
are added for convenience, although only very few of them
are really used in the compiler.

All those "library" function are located in the area from 23D20 to
30AC8 and need 52 k ca.

BTW: I just discovered that I added an unneeded member called PASUTILS,
which could be eliminated, so 8 k could by saved :-)

  $PASUTI#   2E938  4A
  $UTIL003   2E988  C0
  HALT   2EA48  A4
  DATETIME   2EAF0 184
  DATTIM10   2EC78 1C4
  TERMIN 2EE40 290
  TERMOUT    2F0D0 290
  ASSIGN 2F360 320
  ASSIGNME   2F680 1A4
  CLRSCRN    2F828 1B8
  MOVEPARM   2F9E0 178
  TOUPPER    2FB58 104
  TOUPPERS   2FC60 10C
  $UTIL016   2FD70 118
  $UTIL017   2FE88 33C
  DUMPSTOR   301C8 138
  INTTOSTR   30300 284
  IVALSTR    30588 3F8
  READSYMB   30980 144

if you are interested in the compiler, look here:

http://bernd-oppolzer.de/job9.htm

or here:

https://www.facebook.com/StanfordPascal/?ref=aymt_homepage_panel

the compiler runs on old CMS and MVS versions, but on modern z/OS, too 
(limited to AMODE 24,
at the moment), and probably on z/VM (not tested yet). You can download 
the compiler

using the links above.

Kind regards

Bernd

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[Thomas David Rivers]

Frank Swarbrick wrote:


Doesn't that make for fairly large executables?
 



Well - it can - but a trimmed down C library is surprisingly small.

Of course - if you're dragging C++ into this, then things get bigger; but
again - that's not the library usually, it's the templates, etc.. that your
program instantiates...

It seems, in practice, to not be an issue at all.

 - Dave Rivers -




 


Let me also speak as a vendor; for Dignus C/C++ (in he default mode of
operation)
the runtime is linked with the program.  There is no dependency on an
externally
loaded component - or LE.   So, you don't have to worry about version
compatibility.

 - Dave Rivers -

--


 




--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[Paul Gilmartin]

On Tue, 7 Nov 2017 22:07:57 +, Frank Swarbrick wrote:

>Doesn't that make for fairly large executables?
>
That runtime is not monolithic, merely inconveniently megalithic.
Infuriatingly so to a vendor who has chosen to structure its own
product in numerous executables.  I believe Dignus acceded to
one customer's request for finer granularity in that runtime.

>From:  Thomas David Rivers 
>Sent: Monday, November 6, 2017 4:58 AM
>>
>Let me also speak as a vendor; for Dignus C/C++ (in he default mode of 
>operation)
>the runtime is linked with the program.  There is no dependency on an 
>externally
>loaded component - or LE.   So, you don't have to worry about version 
>compatibility.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[Frank Swarbrick]

Doesn't that make for fairly large executables?

From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Thomas David Rivers <riv...@dignus.com>
Sent: Monday, November 6, 2017 4:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C/C++ Runtime Library

Ze'ev Atlas wrote:

>I hope that I word my question correctlyIs the C/C++ Runtime Library installed 
>by default on z/OS  or is it a product that needs to be licensed separately?In 
>other words, if I distribute a software product, written in C, in binary form 
>(load modules) and that product rely on the runtime library, what is the 
>likelihood that the client's installations out there would not be able to run 
>the product because the runtime library is not present?
>Ze'ev Atlas
>
>
>
Let me also speak as a vendor; for Dignus C/C++ (in he default mode of
operation)
the runtime is linked with the program.  There is no dependency on an
externally
loaded component - or LE.   So, you don't have to worry about version
compatibility.

  - Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[Edward Gould]

> On Nov 6, 2017, at 5:58 AM, Thomas David Rivers  wrote:
> 
>> ——SNIP---
>> 
> Let me also speak as a vendor; for Dignus C/C++ (in he default mode of 
> operation)
> the runtime is linked with the program.  There is no dependency on an 
> externally
> loaded component - or LE.   So, you don't have to worry about version 
> compatibility.
> 
Dave,
Great news, glad you guys got it done properly.
I will however tell people about an issue I had with a European vendor.
I won’t mention names as I have long time forgotten them.
One of our users wanted to purchase this package. I installed it (non-smpe) and 
started my test out of the program. No matter how I tried to run it it was OC4 
ing. So I tried the second example of their product and the same thing 0C4.
I called the vendor in Europe and gave them the information and I wanted to 
know what their fax was to send the dumps (these were small dumps 2-3 pages 
each). He wouldn’t hear of it and wanted to go over the dumps on the phone, so 
we did. IIRC I had 3 dumps each of the dump 0C4 showed up in an LE module 
(different one on each dump). At the end he asked what level of LE we were at, 
I don’t remember the number but it seemed like every 6 months LE was coming out 
with a new version (this was approximately 20 years ago). He thought about it 
and he said he would call me back. Which he did about 2 hours later. He told me 
to do an amblist of every module that was in their library and create link 
statements  for each module and to replace every LE module and relink them with 
our LE version. I said you have to be kidding, no he said that is the “fix”. I 
said thanks and good bye. I looked at the amount of work involved and it was a 
healthy amount. So I made an appointment to talk with the boss. When I 
explained what was going on and what the vendor had asked me to do and I was 
guessing 10-15 hours to do the work. He said no you are not going to do this, I 
will talk with them and get them to do it for us. The next day the boss came 
out and told me to throw the work away and to return the tape to them. He then 
called the user and explained that the install process was a lot more intensive 
than what was originally thought and we would not install their software.

Ed  
> - Dave Rivers -
> 
> -- 
> riv...@dignus.comWork: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[Thomas David Rivers]

Ze'ev Atlas wrote:

I hope that I word my question correctlyIs the C/C++ Runtime Library installed by default on z/OS  or is it a product that needs to be licensed separately?In other words, if I distribute a software product, written in C, in binary form (load modules) and that product rely on the runtime library, what is the likelihood that the client's installations out there would not be able to run the product because the runtime library is not present? 
Ze'ev Atlas


 

Let me also speak as a vendor; for Dignus C/C++ (in he default mode of 
operation)
the runtime is linked with the program.  There is no dependency on an 
externally
loaded component - or LE.   So, you don't have to worry about version 
compatibility.


 - Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[Ze'ev Atlas]

Thank you everybody for the answers.The ZS, ARCH and TUNE numbers will be taken 
into account Ze'ev Atlas

 


   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[Charles Mills]

Let me speak as a vendor here. There are two issues.

You can tell the C/C++ compiler both the minimum hardware you intend to support 
and the most typical hardware you intend to run on. So it uses only 
instructions available on that minimum hardware and chooses instructions that 
work best on the typical hardware. We build our product "usually" ARCH(9) 
TUNE(10) -- that means we require a minimum of a z196 but run best on a 
BC/EC12. One of these years we will up that to ARCH(10) TUNE(11).

The wonderful thing about a compiled language is that we have the occasional 
POC or customer who is on a z9. No problem -- we just do a recompile and a 
special build for ARCH(7) TUNE(7).

Any assembler routines in your product are a different matter. You can't "just 
reassemble ZS-2." So we always build all our (minimal number of) assembler 
routines ZS-5 (z9). You lose a lot of great instructions, but c'est la vie.

(The C ARCH numbers are two behind the marketing numbers: a z13 is ARCH(11). 
The HLASM MACHINE numbers are four behind: a z13 is ZS-9.)

The software checks and detects if it is compiled ARCH(9) but you are trying to 
run it on a z10, and exits gracefully, without ever getting into C code 
compiled for a z196.

You also tell the C/C++ compiler and the binder the minimum level of LE to 
target. We tell the compiler TARG(LE,zOSV1R13) and it squawks if you try to use 
a function not available until later. At this moment I do not know what happens 
if you try to run on V1R12: I would hope that the LE runtime squawks, albeit 
probably in the most obscure way possible.

If you had a vendor product problem in this regard then my guess is that it was 
carelessness on the vendor's part. Possibly an oops on IBM's part, but I think 
the vendor's part is more likely. We regression test on all of the levels of 
z/OS we claim to support. We do some hardware level testing, but not much, and 
have not had an unexpected problem with hardware levels -- or z/OS versions, 
for that matter.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Sunday, November 5, 2017 8:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C/C++ Runtime Library

Just a thought.

>From a vendor perspective I would think you would need a test in your process 
>to verify that the microcode/firmware and LE runtime libraries will work for 
>that shop.

For example, if you use XYZ in C language but that support did not show up 
until z/OS V1.12.  The shop installing the code is at z/OS 1.10.  I would think 
that would cause an error for the customer.

I had a case with a vendor product, where the developer used a cool new 
instruction.  Unfortunately it was for a higher level of firmware than the CPU 
we were running on at the time.  This caused an S0C4.  This required a SEV1 
immediate fix situation.

I am not sure how much testing in the code that vendors need to do to support 
any level of hardware or software for their products.

But I would think some would need to be done.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[Lizette Koehler]

Just a thought.

>From a vendor perspective I would think you would need a test in your process 
>to verify that the microcode/firmware and LE runtime libraries will work for 
>that shop.

For example, if you use XYZ in C language but that support did not show up 
until z/OS V1.12.  The shop installing the code is at z/OS 1.10.  I would think 
that would cause an error for the customer.

I had a case with a vendor product, where the developer used a cool new 
instruction.  Unfortunately it was for a higher level of firmware than the CPU 
we were running on at the time.  This caused an S0C4.  This required a SEV1 
immediate fix situation.

I am not sure how much testing in the code that vendors need to do to support 
any level of hardware or software for their products.

But I would think some would need to be done.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Sunday, November 05, 2017 8:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: C/C++ Runtime Library
> 
> Be aware also of https://ibm.co/2hHaJPC
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Sunday, November 5, 2017 5:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: C/C++ Runtime Library
> 
> On Sat, Nov 4, 2017 at 9:48 PM, Ze'ev Atlas < 004b34e7c98a-dmarc-
> requ...@listserv.ua.edu> wrote:
> 
> > I hope that I word my question correctlyIs the C/C++ Runtime Library
> > installed by default on z/OS  or is it a product that needs to be
> > licensed separately?In other words, if I distribute a software
> > product, written in C, in binary form (load modules) and that product
> > rely on the runtime library, what is the likelihood that the client's
> > installations out there would not be able to run the product because
> > the runtime library is not present?
> > Ze'ev Atlas
> >
> >
> ​The C/C++ run time libraries, along with the PL/I & Fortran run times, are
> all distributed with z/OS and licensed for use with z/OS. Together, they are
> "Language Environment", aka LE.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[Charles Mills]

Be aware also of https://ibm.co/2hHaJPC 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Sunday, November 5, 2017 5:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C/C++ Runtime Library

On Sat, Nov 4, 2017 at 9:48 PM, Ze'ev Atlas < 
004b34e7c98a-dmarc-requ...@listserv.ua.edu> wrote:

> I hope that I word my question correctlyIs the C/C++ Runtime Library 
> installed by default on z/OS  or is it a product that needs to be 
> licensed separately?In other words, if I distribute a software 
> product, written in C, in binary form (load modules) and that product 
> rely on the runtime library, what is the likelihood that the client's 
> installations out there would not be able to run the product because 
> the runtime library is not present?
> Ze'ev Atlas
>
>
​The C/C++ run time libraries, along with the PL/I & Fortran run times, are all 
distributed with z/OS and licensed for use with z/OS. Together, they are 
"Language Environment", aka LE.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: C/C++ Runtime Library

[John McKown]

On Sat, Nov 4, 2017 at 9:48 PM, Ze'ev Atlas <
004b34e7c98a-dmarc-requ...@listserv.ua.edu> wrote:

> I hope that I word my question correctlyIs the C/C++ Runtime Library
> installed by default on z/OS  or is it a product that needs to be licensed
> separately?In other words, if I distribute a software product, written in
> C, in binary form (load modules) and that product rely on the runtime
> library, what is the likelihood that the client's installations out there
> would not be able to run the product because the runtime library is not
> present?
> Ze'ev Atlas
>
>
​The C/C++ run time libraries, along with the PL/I & Fortran run times, are
all distributed with z/OS and licensed for use with z/OS. Together, they
are "Language Environment", aka LE.


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

C/C++ Runtime Library

[Ze'ev Atlas]

I hope that I word my question correctlyIs the C/C++ Runtime Library installed 
by default on z/OS  or is it a product that needs to be licensed separately?In 
other words, if I distribute a software product, written in C, in binary form 
(load modules) and that product rely on the runtime library, what is the 
likelihood that the client's installations out there would not be able to run 
the product because the runtime library is not present? 
Ze'ev Atlas


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN