Re: Friday OT, cheerful program for gloomy times
They say that the memory is the second thing to go; I don't remember the first thing. Given that Mike Cowlishaw was involved in developing ANSI X3.274-1996, I'm pretty sure that he would claim that to be the standard Rexx language, just as I'm pretty sure that John Backus would consider X3.9-1966, X3.9-1978, etc., to be standard Fortran, not what ran on the 704. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponce...@bcs.org.uk] Sent: Saturday, April 25, 2020 11:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday OT, cheerful program for gloomy times "ON NO VALUE" from memory. "supports the standard Rexx language" as per Mike Cowlishaw's definition (COW). Comparison of Built-In Functions The following table provides a comparison of Built-In Functions for VM/SP CMS REXX (CMS), M.F. Cowlishaw's definition (COW), Systems Application Architecture Procedures Language (SAA), and CTC REXX. Table 3. Comparison of Built-in Functions Availability of Built-in Functions FunctionSAA COW CMS CTC ABBREVx x x x ABS x x x x ADDRESS x x x x ARG x x x x BITANDx x x x BITOR x x x x BITXORx x x x B2X x - - x CENTERx x x x CHARINx x - x CHAROUT x x - x CHARS x x - x COMPARE x x x x CONDITION x - - x COPIESx x x x C2D x x x x C2X x x x x DATATYPE x x x x DATE x x x x DELSTRx x x x DELWORD x x x x DIGITSx x x x D2C x x x x D2X x x x x ERRORTEXT x x x x FORM x x x x FORMATx x x x FUZZ x x x x INSERTx x x x LASTPOS x x x x LEFT x x x x LENGTHx x x x LINEINx x - x LINEOUT x x - x LINES x x - x MAX x x x x MIN x x x x OVERLAY x x x x POS x x x x QUEUEDx x x x RANDOMx x x x REVERSE x x x x RIGHT x x x x SIGN x x x x SOURCELINEx x x x SPACE x x x x STREAMx - - x STRIP x x x x SUBSTRx x x x SUBWORD x x x x SYMBOLx x x x TIME x x x x TRACE x x x x TRANSLATE x x x x TRUNC x x x x VALUE x x x x VERIFYx x x x WORD x x x x WORDINDEX x x x x WORDLENGTHx x x x WORDPOS x x x x WORDS x x x x XRANGEx x x x X2B x - - x X2C x x x x X2D x x x x On 26/04/2020 02:35, Seymour J Metz wrote: >> After commenting out the "SIGNAL ON NO VALUE" > "SIGNAL ON
Re: Cobol
People seem to identify as "modern" what they learned at University. I didn't attend a University, at the time it was a Polytechnic. We learned Fortran on an ICL machine (no idea what model). I thought programming was not for me based on what we were taught, rather for the next man. Reminds me of the line in the Goons: Bloodnot : " I'm saner than the next man! " Eccles: "Little does he know, I'm the next man." A couple of years later I was poring over the IBM Orientation manuals, gazing out of the window thinking "what have I done". On Sun, Apr 26, 2020 at 7:44 AM Charles Mills wrote: > Funny, isn’t it? > > COBOL (née 1959) is 61 years old. It’s a very old language. > > C (née 1972) is 48 years old. It’s a modern language. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Rob Schramm > Sent: Saturday, April 25, 2020 1:56 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cobol > > So age-ist to comment on C's age. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol
Can't resist: The Call of the West Eccles: The wagon train with your wife on board has been attacked by the Indians! Captain: My wife? Is she safe? Eccles: Yeah. Captain: I never did like them Indians. Lt. Hern: Did they follow you? Eccles: Yeah. They were shooting at me all the time. But I just stuck my tongue out at them. Lt. Hern: Get wounded? Eccles: Yeah. Lt. Hern: Where? Eccles: In the tongue. On Sun, Apr 26, 2020 at 6:18 PM Wayne Bickerdike wrote: > People seem to identify as "modern" what they learned at University. > > I didn't attend a University, at the time it was a Polytechnic. We learned > Fortran on an ICL machine (no idea what model). > > I thought programming was not for me based on what we were taught, rather > for the next man. > > Reminds me of the line in the Goons: > > Bloodnot : " I'm saner than the next man! " > > Eccles: "Little does he know, I'm the next man." > > A couple of years later I was poring over the IBM Orientation manuals, > gazing out of the window thinking "what have I done". > > > > > > > On Sun, Apr 26, 2020 at 7:44 AM Charles Mills wrote: > >> Funny, isn’t it? >> >> COBOL (née 1959) is 61 years old. It’s a very old language. >> >> C (née 1972) is 48 years old. It’s a modern language. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Rob Schramm >> Sent: Saturday, April 25, 2020 1:56 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Cobol >> >> So age-ist to comment on C's age. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > -- > Wayne V. Bickerdike > > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol
On Fri, Apr 24, 2020 at 7:12 PM Seymour J Metz wrote: > Hey, it's not politically correct to point out how old C is. > I always thought it was named "C" because that would have been the grade a student would have gotten if he/she had designed it in a modern computer science class. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C
HLASM in 1980? Not before June 1992. I assume that you were using XF and H, possibly with the SLAC mods on the latter (thank you, Greg and John.) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Donald Blake [dhbl...@gmail.com] Sent: Sunday, April 26, 2020 8:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: C I took my first C course in 1980. The text was the original *The C programming Language* by Kerrigan and Richie, which I still have on my shelf, The text is copyright 1978. That's 42 years ago. I was an IBM HL Assembler programmer at the time. BTW ... we still were using IFOX00 at the time as well. > Hey, it's not politically correct to point out how old C is. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > -- 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: Friday OT, cheerful program for gloomy times
OREXX in OS/2:
Sun 4-26-20 10:16:16Sun 4-26-20 10:16:16{1}[h:\] H:\$REXX\trynot.cmd
Trying \ 5C
\ recognized
Trying ¬ AA
¬ recognized
Trying ¼ AC
6 *-* compare = a ¼
6 *-* interpret 'compare = a' Not'= b'
REX0013E: Error 13 running H:\$REXX\TRYNOT.CMD line 6: Invalid character in
program
REX0219E: Error 13.1: Incorrect character in program "¼" ('AC'X)
Code pages 437 and 850 have ¬ at AA and ¼ at AC.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Joel C. Ewing [jcew...@acm.org]
Sent: Sunday, April 26, 2020 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times
On 4/25/20 3:51 PM, Paul Gilmartin wrote:
> I did not copy-and-paste; I downloaded the attachment,
> which appears to be UTF-8.
>
> For Regina, Regina.pdf says: 3.1.1.1 Negators
> ... Regina supports the following characters as negators:
> ...
> ¬ Logical Not
> Copy-and-paste from the pdf gives me:
> 931 $ printf ¬ | od -tx1
> 000c2 ac
> ... the UTF-8 "¬". But when I paste it into an EXEC, Regina says:
> say 2+2 ¬= 4
> Error 13 running "/Users/paulgilm/bin/rxx", line 2: Invalid character in
> program
> Error 13.1: Invalid character in program "('c2'X)"
>
> I much prefer when the examples in the Ref. actually work. Does
> ooRexx accept UTF-8 "¬"?
>
> I went on and did something fancy. Attached.
On Linux oorexx accepts UTF-8 "¬" , but can't speak for oorexx in M$
environment; and also seems to work for all in Seymour's nots list (Nots
= '\' 'aa'x 'ac'x), but am at a loss to remember context for using
'aa'x as a logical not -- displays as "feminine ordinal indicator" "ª"
in gedit on Linux.
Joel C. Ewing
--
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: Friday OT, cheerful program for gloomy times
On Sun, 26 Apr 2020 07:39:27 +, Seymour J Metz wrote:
>They say that the memory is the second thing to go; I don't remember the first
>thing.
>
>Given that Mike Cowlishaw was involved in developing ANSI X3.274-1996, I'm
>pretty sure that he would claim that to be the standard Rexx language, just as
>I'm pretty sure that John Backus would consider X3.9-1966, X3.9-1978, etc.,
>to be standard Fortran, not what ran on the 704.
>
I find this akin to expecting all software to follow the antiquated
MSDOS 8.3 filename format convention.
>
>From: CM Poncelet
>Sent: Saturday, April 25, 2020 11:40 PM
>
>"ON NO VALUE" from memory.
>
At one time, IBM's Rexx compiler considered SIGNAL ON NOVALUE (sic) a
syntax error if the label was not supplied. I think it got better shortly.
>"supports the standard Rexx language" as per Mike Cowlishaw's definition
>(COW).
>
> Comparison of Built-In Functions
>
> The following table provides a comparison of Built-In Functions
> for VM/SP CMS REXX (CMS), M.F. Cowlishaw's definition (COW),
> Systems Application Architecture Procedures Language (SAA), and
> CTC REXX.
>
> Table 3. Comparison of Built-in Functions
>
>
> Availability of Built-in Functions
>
> FunctionSAA COW CMS CTC
>...
> CHARINx x - x
> CHAROUT x x - x
> CHARS x x - x
> ...
> DATE x x x x
> ...
But no discussion of supported operand formats.
> LINEINx x - x
> LINEOUT x x - x
>...
> STREAMx - - x
>...
CMS Rexx has supported the *standard* stream I/O for many releases.
Where does one find SAA nowadays. Mostly, I remember its incursion
was disruptive by scrambling ISPF's familiar PF key assignments.
>>> See below for the SPF/PC standard Rexx one.
>>>
I don't believe SPF/PC governs the standard for either Rexx or Java.
>> DATE('B',foo,'S') is valid in standard Rexx. I don't believe that the first
>> and third
>>parameters are allowed to be longer than 1 character.
>>
They're truncated. Characters beyond the initial are irrelevant.
>> From: CM Poncelet
>> Sent: Saturday, April 25, 2020 7:10 PM
>>
>> Have you checked that your version works, other than on a mainframe?
>>
Regina, yes.
>> SPF/PC Rexx supports the standard Rexx language, but not the full IBM
>> REXX (which includes EXECIO etc.) and it does not recognise your format
>> of DATE parms. ...
>>
SPF/PC, perhaps; standard, no.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
C
I took my first C course in 1980. The text was the original *The C programming Language* by Kerrigan and Richie, which I still have on my shelf, The text is copyright 1978. That's 42 years ago. I was an IBM HL Assembler programmer at the time. BTW ... we still were using IFOX00 at the time as well. > Hey, it's not politically correct to point out how old C is. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Request: Examples of an IPCS RUNARRAY command where the EXEC clause display storage using a pointer as a displacement off of X
I would like to see an examples of an IPCS RUNARRAY command where the EXEC clause display storage using a pointer as a displacement off of X. So far I have not been able to make it work. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
XL C\C ++ sizeof of datatypes
HI I am looking in the XL C docs lang reference user guide programming guide For the length of the following data types Short , int long and I cannot seem to find it frustrated I coded a program Int len; Unsigned short shortype; Int len = sizeof(shorttype); But the compiler seemed to comment the above statement and not generate the assembler ps (I am running metal c); Any help appreciate it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol
I would have assigned it an E at the time; I was appalled. C++ cleans up some but not all of the warts, and a lot of the warts in C++ are there only for compatibility. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of John McKown [john.archie.mck...@gmail.com] Sent: Sunday, April 26, 2020 8:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol On Fri, Apr 24, 2020 at 7:12 PM Seymour J Metz wrote: > Hey, it's not politically correct to point out how old C is. > I always thought it was named "C" because that would have been the grade a student would have gotten if he/she had designed it in a modern computer science class. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- 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: Cobol
The is a PL/AS and a PL/X, both ultimately derived from BSL (the languages, not the code base.) AFAIK there is no PL/ASX. Does anybody remember the full family tree for BSL, PL/8 (or should that be PL.8?) et al? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Rob Schramm [rob.schr...@gmail.com] Sent: Saturday, April 25, 2020 4:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol So age-ist to comment on C's age. Lol I wonder when someone is going to write a javac that actually produces C code for the platform. Kind of like PL/asx ( I may have this acro wrong ) Write once and compile and run quicker anywhere. Rob Schramm On Sat, Apr 25, 2020, 00:20 Wayne Bickerdike wrote: > In the same conversation was the adage that GDGs are great and that's what > makes z/OS so irreplaceable. I said what? > > On Sat, Apr 25, 2020 at 10:12 AM Seymour J Metz wrote: > > > Hey, it's not politically correct to point out how old C is. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > > of Wayne Bickerdike [wayn...@gmail.com] > > Sent: Friday, April 24, 2020 7:03 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Cobol > > > > One of our guys was talking about modern languages such as C. I said > what? > > > > On Sat, Apr 25, 2020 at 7:01 AM Seymour J Metz wrote: > > > > > Well what do you know? The emperor has no clothes. We shot an innocent > > > language. > > > > > > > > > -- > > > Shmuel (Seymour J.) Metz > > > http://mason.gmu.edu/~smetz3 > > > > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf > > > of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] > > > Sent: Friday, April 24, 2020 3:58 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Cobol > > > > > > On Fri, 24 Apr 2020 18:26:49 +, Seymour J Metz wrote: > > > > > > >There are blurbs for dozens of articles; which one is relevant? I > tried > > > searxhing for COBOL, but got 0 hits. > > > > > > > I suspect that was OP's desperate and futile attempt to circumvent > > > secureweb, > > > as you often do. But, I hope (posting from web interface): > > > > > > > > > https://secure-web.cisco.com/18wMr2wQiot_mC2NJkJL7buWujrBfP9suLfEWZL4dG8gjB_Zjaj31ZgILnrnn--CfD_RooCYfsFjxvxArhRiN2V2tCmTfs8NayUQCV2ProhQ0KfRlDMDZdg2alKOSjuWwTXeK_Lci9elkht49bjva6Fj7o1W1SIr2REv9PF2NO_PK0BStoe0irBBLJRM9a_tKg3QNHj3DghbIM6_s_J2QBa8K1XWudsYnadGx1bdpDNNTapriOq_jLHjoC742AxmqQVAJ4Szwl0aLrINIHWnzPzP_p0N_kYOi4keUEoOLuWRccU_ZVES-3NC05VlKLovPbiDfx9BUbsi3Kn4nGo1sHGipsJJfPFN4ClnEGuuMjWs6LU9f2293Fm0jTt3GhayZHNNDR8prcppx857Qz_vQpR6HOUIxm-p1DAvFYE8aFU_B3Da9y60snIIWQxr9qfkI67XWmwAvbGdgFfA9cP_uBHV85oupnnYfOSco5uQPIVE/https%3A%2F%2Fwww.wired.com%2Fstory%2Fcant-file-unemployment-dont-blame-cobol%2F > > > > > > > > > From: scott Ford > > > Sent: Friday, April 24, 2020 2:08 PM > > > > > > See this url ... > > > > > > > > > > > > http://secure-web.cisco.com/1DYCAeckpzqV94PQWw8dHuuJalhW0eVroAe-0-S4pJl_FnqGfZxS4EcWK7cCAl1oA09gJJKNMcHC1Be4KK3D-KcMIEVRVBeNOw5sf7565Z6e9CTYIm43a-oit3GGWnum7LgBTpYCxV6CAhgR9TuXipYHaUjUUPtd7BICMs1zfFGQQ8NhAeXHdXvHPrGdxzaQmTRfNi8vGWGKk4fg_G75au8H3Ja9AbLwRb2m8-upI9jYdmy1ZYdzYlRF2kzlwN155wAFEug02LCkZ5Bpk3IvSuxwzwd1UUyk_5NUmIqwMFmcDxZ8SpSnwFspncJTV1bLmByZAIVczBfj-JctXDA5Ta99YBqxx1tBpdl0qN5MWPGsz1CGAQ_Is1sLoRxy9Dl_fCLgMhLDvO5L8-EsVff2IiswF1xKvwUDiAEPcV0mOxz5c915mExQuVbCTDL0KTJQEtCF5dYTiss8HJIK_dzSG8g/http%3A%2F%2Fwww.wired.com > > . > > > Can't File for Unemployment - Don�t Blame Cobol > > > > > > -- gil > > > > > > -- > > > 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 > > > > > > > > > -- > > Wayne V. Bickerdike > > > > -- > > 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 > > > > > -- > Wayne V. Bickerdike > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with
Re: Friday OT, cheerful program for gloomy times
On 4/25/20 3:51 PM, Paul Gilmartin wrote:
> I did not copy-and-paste; I downloaded the attachment,
> which appears to be UTF-8.
>
> For Regina, Regina.pdf says: 3.1.1.1 Negators
> ... Regina supports the following characters as negators:
> ...
> ¬ Logical Not
> Copy-and-paste from the pdf gives me:
> 931 $ printf ¬ | od -tx1
> 000c2 ac
> ... the UTF-8 "¬". But when I paste it into an EXEC, Regina says:
> say 2+2 ¬= 4
> Error 13 running "/Users/paulgilm/bin/rxx", line 2: Invalid character in
> program
> Error 13.1: Invalid character in program "('c2'X)"
>
> I much prefer when the examples in the Ref. actually work. Does
> ooRexx accept UTF-8 "¬"?
>
> I went on and did something fancy. Attached.
On Linux oorexx accepts UTF-8 "¬" , but can't speak for oorexx in M$
environment; and also seems to work for all in Seymour's nots list (Nots
= '\' 'aa'x 'ac'x), but am at a loss to remember context for using
'aa'x as a logical not -- displays as "feminine ordinal indicator" "ª"
in gedit on Linux.
Joel C. Ewing
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol
On 4/25/20 2:56 PM, Rob Schramm wrote: I wonder when someone is going to write a javac that actually produces C code for the platform. Kind of like PL/asx ( I may have this acro wrong ) Modern Java VMs are about as efficient as can be, given the object model. That's why the notion of Java -> C compilers went away. -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Java (was: Cobol)
On 2020-04-26, at 08:41:24, Jack J. Woehr wrote: > > On 4/25/20 2:56 PM, Rob Schramm wrote: >> I wonder when someone is going to write a javac that actually produces C >> code for the platform. Kind of like PL/asx ( I may have this acro wrong ) > > Modern Java VMs are about as efficient as can be, given the object model. > With the advantage of JIT compilation/optimization. > That's why the notion of Java -> C compilers went away. > Is there any residual portability concern? But how portable is ANSI C? The gyrations of GNU configure make me wonder. The java samples at http://math.hws.edu/eck/js/mandelbrot/java/MB-java.html are splendid. They work alike on: MacOS, Linux (Intel and Raspberry π), and z/OS (output to JPEG; never got X11 client configured.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
Don't allow extraneous factors (such as optimization or argument promotions)
to obfuscate the information you want. If you want the sizes of the types,
print the sizes of the types.
#include
int main(void)
{
printf("%zd %zd %zd", sizeof(short), sizeof(int), sizeof(long));
return 0;
}
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Joseph Reichman
> Sent: Sunday, April 26, 2020 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: XL C\C ++ sizeof of datatypes
>
> HI
>
>I am looking in the XL C docs lang reference user guide programming
guide
> For the length of the following data types
> Short , int long and I cannot seem to find it
> frustrated
>
> I coded a program
>
> Int len;
> Unsigned short shortype;
> Int len = sizeof(shorttype);
>
>But the compiler seemed to comment the above statement
> and not generate the assembler ps (I am running metal c);
>
> Any help appreciate it
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday OT, cheerful program for gloomy times
Mike Cowlishaw created the Rexx language
https://en.wikipedia.org/wiki/Mike_Cowlishaw
On 26/04/2020 15:48, Paul Gilmartin wrote:
> On Sun, 26 Apr 2020 07:39:27 +, Seymour J Metz wrote:
>
>> They say that the memory is the second thing to go; I don't remember the
>> first thing.
>>
>> Given that Mike Cowlishaw was involved in developing ANSI X3.274-1996, I'm
>> pretty sure that he would claim that to be the standard Rexx language, just
>> as I'm pretty sure that John Backus would consider X3.9-1966, X3.9-1978,
>> etc., to be standard Fortran, not what ran on the 704.
>>
> I find this akin to expecting all software to follow the antiquated
> MSDOS 8.3 filename format convention.
>
>>
>> From: CM Poncelet
>> Sent: Saturday, April 25, 2020 11:40 PM
>>
>> "ON NO VALUE" from memory.
>>
> At one time, IBM's Rexx compiler considered SIGNAL ON NOVALUE (sic) a
> syntax error if the label was not supplied. I think it got better shortly.
>
>> "supports the standard Rexx language" as per Mike Cowlishaw's definition
>> (COW).
>>
>> Comparison of Built-In Functions
>>
>> The following table provides a comparison of Built-In Functions
>> for VM/SP CMS REXX (CMS), M.F. Cowlishaw's definition (COW),
>> Systems Application Architecture Procedures Language (SAA), and
>> CTC REXX.
>>
>> Table 3. Comparison of Built-in Functions
>>
>>
>> Availability of Built-in Functions
>>
>> FunctionSAA COW CMS CTC
>>...
>> CHARINx x - x
>> CHAROUT x x - x
>> CHARS x x - x
>> ...
>> DATE x x x x
>> ...
> But no discussion of supported operand formats.
>
>> LINEINx x - x
>> LINEOUT x x - x
>>...
>> STREAMx - - x
>>...
> CMS Rexx has supported the *standard* stream I/O for many releases.
>
> Where does one find SAA nowadays. Mostly, I remember its incursion
> was disruptive by scrambling ISPF's familiar PF key assignments.
>
See below for the SPF/PC standard Rexx one.
> I don't believe SPF/PC governs the standard for either Rexx or Java.
>
>>> DATE('B',foo,'S') is valid in standard Rexx. I don't believe that the first
>>> and third
>>> parameters are allowed to be longer than 1 character.
>>>
> They're truncated. Characters beyond the initial are irrelevant.
>
>
>>> From: CM Poncelet
>>> Sent: Saturday, April 25, 2020 7:10 PM
>>>
>>> Have you checked that your version works, other than on a mainframe?
>>>
> Regina, yes.
>
>>> SPF/PC Rexx supports the standard Rexx language, but not the full IBM
>>> REXX (which includes EXECIO etc.) and it does not recognise your format
>>> of DATE parms. ...
>>>
> SPF/PC, perhaps; standard, no.
>
> -- gil
>
> --
> 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: XL C\C ++ sizeof of datatypes
+1
Or RTFKC:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
.cbclx01/zos_supporting_ansi_iso_standards.htm
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of retired mainframer
Sent: Sunday, April 26, 2020 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
Don't allow extraneous factors (such as optimization or argument promotions)
to obfuscate the information you want. If you want the sizes of the types,
print the sizes of the types.
#include
int main(void)
{
printf("%zd %zd %zd", sizeof(short), sizeof(int), sizeof(long));
return 0;
}
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Joseph Reichman
> Sent: Sunday, April 26, 2020 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: XL C\C ++ sizeof of datatypes
>
> HI
>
>I am looking in the XL C docs lang reference user guide programming
guide
> For the length of the following data types
> Short , int long and I cannot seem to find it
> frustrated
>
> I coded a program
>
> Int len;
> Unsigned short shortype;
> Int len = sizeof(shorttype);
>
>But the compiler seemed to comment the above statement
> and not generate the assembler ps (I am running metal c);
>
> Any help appreciate it
--
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: XL C\C ++ sizeof of datatypes compiler bug ?
On Sun, 26 Apr 2020 13:38:49 -0400, Joseph Reichman wrote:
>Tried that great idea however I think you helped me uncover a bug in the
>compiler
>So it seems that a short is 2 bytes look below
>
>However when I passed reclen as a parameter it was by value not by address
>guess what the compiler did
>
> L R14,@...RECLEN
> ST R14,232(R13)
>
>I would of thought it would be STH ?
>
Some of this antedates function prototypes, when the specification was to
widen char and short actual parameters to (long?) int on the stack, and
float to double.
This got me in trouble with Whitesmith compiler when I had such as:
f( char c) {
g( );
}
The compiler passed the address of the int it expected on the stack.
Woulda worked on little-endian, where they probably developed and
tested it.
>
> * len = sizeof(reclen);
> LA15,2
> ST15,@111len
>* return len;
> NILH 15,X''
> NILH 15,X''
> BRU @1L38
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SP macros
We had a similar package of SP (structured programming) macros in Germany, very powerful (IF...THEN...ELSE...EIF, LOOP WHILE/UNTIL...ELOOP etc.). Most interesting: there were always multiple conditions on IF and LOOP, separated by asterisks, so IF...THEN(1)...THEN(2)...THEN(3)...ELSE...EIF in fact was more a CASE (or SWITCH) statement and LOOP WHILE ... OUT(1)...OUT(2)...OUT(3)...ELOOP was very powerful, too (and there was BREAK, too, of course). Some macros even supported procedure blocks with separate base registers, which allowed very large programs using only two or four base registers, if used correctly. The SP macros are still in use at different large mainframe users in Germany; when I started work at Allianz Versicherung (insurance) in 1990 ca., I was told that they originated from Quelle Versandhaus (mail order company, bankrupt in 2009), but I am not sure about that. My first task at Allianz was to teach ASSEMBLER to some 15 newbies, and of course I had to teach the SP macros, too (every new program had to make use of them, the use of normal branch operations was forbidden). In 2014, I changed the SP macros at Allianz Versicherung to generate relative branches and support baseless coding, which was about the last project I did there. Kind regards Bernd Am 26.04.2020 um 19:35 schrieb Seymour J Metz: Those macros were not part of the assembler. As I recall there was a popular macro package called CONCEPT 101 (sp?) floating around, and another package called PROC, but they didn't come from IBM. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Mike Schwab [mike.a.sch...@gmail.com] Sent: Sunday, April 26, 2020 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C I was doing an internship in the Chicago area during the summer of 1984. They were using an assembler with IF macros. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
The question and the subject do not seem to go together. Shorts are 16 bits; long and long ints are 32 bits on most modern C compilers. As @John says, statements that "don't matter" go away. If you set len and then do not use it, the compiler is free to disregard the setting. Try the volatile attribute and see if that helps. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman Sent: Sunday, April 26, 2020 6:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XL C\C ++ sizeof of datatypes HI I am looking in the XL C docs lang reference user guide programming guide For the length of the following data types Short , int long and I cannot seem to find it frustrated I coded a program Int len; Unsigned short shortype; Int len = sizeof(shorttype); But the compiler seemed to comment the above statement and not generate the assembler ps (I am running metal c); Any help appreciate it -- 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: Java (was: Cobol)
Some of the portability issues have (mostly) gone away because of changes in the language and the demise of, e.g., 36-bit computers as a significant presence in the market place, and some you have to handle on an ad hoc basis with #if and #ifdef in your header files. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Sunday, April 26, 2020 11:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Java (was: Cobol) On 2020-04-26, at 08:41:24, Jack J. Woehr wrote: > > On 4/25/20 2:56 PM, Rob Schramm wrote: >> I wonder when someone is going to write a javac that actually produces C >> code for the platform. Kind of like PL/asx ( I may have this acro wrong ) > > Modern Java VMs are about as efficient as can be, given the object model. > With the advantage of JIT compilation/optimization. > That's why the notion of Java -> C compilers went away. > Is there any residual portability concern? But how portable is ANSI C? The gyrations of GNU configure make me wonder. The java samples at http://secure-web.cisco.com/1gtkcrK5_Jm1BC7hqGY6kmWAuewOT2AVaTtqvC8DOMkF4JltYFqNDT_4ZewLUYqn-R-SemKmpsL3RJo0JsTAHXGmjaB9eoXnv7QU3542u0nqGV2D7O7i11wfWDHiF8N9evaHYF2mG5gCv4ys28fDysP6K9ALMJtBH0h_7o2jHqGegfPkah9JYdSbgTtfq4jrih-l83xzqPekGIBCyc9d3Zyzt-l4msgApk7uwkTtQLrZuq3Pms1wgmKlrUlK3CbMrP3Cj7fFBHRkpkSbgs-myDO-xqCX3s7yod1NaqoN4gbFRigknUcxZ7Y6iR08hReFH4Hi-l599siRDob1H8E3MmhFMf4Yk6YClb5ILuTyTCNadL6FUHvR6L8iIFEPmNiSC-ugA1JmSV0OvPpl0bPKu6lvgJyvS1t0de5xsZ6teppsNJfLSmHmZNeZo-g2wC_Zb/http%3A%2F%2Fmath.hws.edu%2Feck%2Fjs%2Fmandelbrot%2Fjava%2FMB-java.html are splendid. They work alike on: MacOS, Linux (Intel and Raspberry π), and z/OS (output to JPEG; never got X11 client configured.) -- gil -- 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
I was doing an internship in the Chicago area during the summer of 1984. They were using an assembler with IF macros. On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote: > > HLASM in 1980? Not before June 1992. I assume that you were using XF and H, > possibly with the SLAC mods on the latter (thank you, Greg and John.) > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Donald Blake [dhbl...@gmail.com] > Sent: Sunday, April 26, 2020 8:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: C > > I took my first C course in 1980. The text was the original *The C > programming Language* by Kerrigan and Richie, which I still have on my > shelf, The text is copyright 1978. That's 42 years ago. I was an IBM HL > Assembler programmer at the time. BTW ... we still were using IFOX00 at the > time as well. > > > Hey, it's not politically correct to point out how old C is. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > -- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C
Those macros were not part of the assembler. As I recall there was a popular macro package called CONCEPT 101 (sp?) floating around, and another package called PROC, but they didn't come from IBM. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Mike Schwab [mike.a.sch...@gmail.com] Sent: Sunday, April 26, 2020 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C I was doing an internship in the Chicago area during the summer of 1984. They were using an assembler with IF macros. On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote: > > HLASM in 1980? Not before June 1992. I assume that you were using XF and H, > possibly with the SLAC mods on the latter (thank you, Greg and John.) > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Donald Blake [dhbl...@gmail.com] > Sent: Sunday, April 26, 2020 8:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: C > > I took my first C course in 1980. The text was the original *The C > programming Language* by Kerrigan and Richie, which I still have on my > shelf, The text is copyright 1978. That's 42 years ago. I was an IBM HL > Assembler programmer at the time. BTW ... we still were using IFOX00 at the > time as well. > > > Hey, it's not politically correct to point out how old C is. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > -- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: XL C\C ++ sizeof of datatypes
On Sun, Apr 26, 2020 at 8:58 AM Joseph Reichman
wrote:
> HI
>
>I am looking in the XL C docs lang reference user guide programming
> guide
>
> For the length of the following data types
>
>
>
> Short , int long and I cannot seem to find it
>
>
>
> frustrated
>
>
>
> I coded a program
>
> Int len;
>
> Unsigned short shortype;
>
> Int len = sizeof(shorttype);
>But the compiler seemed to comment the above statement
> and not generate the assembler ps (I am running metal c);
> Any help appreciate it
>
I don't know about about Metal C, but if you use regular C with
optimization, and don't use a variable, the compiler simly won't generate
any code to create or initialize it. Perhaps you could use a program kike:
int main() {
unsigned short shorttype;
int len=sizeof(shorttype);
return len;
}
But, then again, you didn't show us the entire program.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes compiler bug ?
Tried that great idea however I think you helped me uncover a bug in the
compiler
So it seems that a short is 2 bytes look below
However when I passed reclen as a parameter it was by value not by address
guess what the compiler did
L R14,@...RECLEN
ST R14,232(R13)
I would of thought it would be STH ?
* len = sizeof(reclen);
LA15,2
ST15,@111len
* return len;
NILH 15,X''
NILH 15,X''
BRU @1L38
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
John McKown
Sent: Sunday, April 26, 2020 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
On Sun, Apr 26, 2020 at 8:58 AM Joseph Reichman mailto:reichman...@gmail.com> >
wrote:
> HI
>
>I am looking in the XL C docs lang reference user guide programming
> guide
>
> For the length of the following data types
>
>
>
> Short , int long and I cannot seem to find it
>
>
>
> frustrated
>
>
>
> I coded a program
>
> Int len;
>
> Unsigned short shortype;
>
> Int len = sizeof(shorttype);
>But the compiler seemed to comment the above
> statement and not generate the assembler ps (I am running metal c);
> Any help appreciate it
>
I don't know about about Metal C, but if you use regular C with optimization,
and don't use a variable, the compiler simly won't generate any code to create
or initialize it. Perhaps you could use a program kike:
int main() {
unsigned short shorttype;
int len=sizeof(shorttype);
return len;
}
But, then again, you didn't show us the entire program.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the
> message: INFO IBM-MAIN
>
--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown
--
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
I thought the macros were part of CONCEPT 14? I do remember working on IBM 3684 point of sale systems between 1982 and 1986. They were programmed using an Asembler like language called SPSS II, it had IF THEN ELSE and other macros. On Mon, Apr 27, 2020, 03:36 Seymour J Metz wrote: > Those macros were not part of the assembler. As I recall there was a > popular macro package called CONCEPT 101 (sp?) floating around, and another > package called PROC, but they didn't come from IBM. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Mike Schwab [mike.a.sch...@gmail.com] > Sent: Sunday, April 26, 2020 1:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: C > > I was doing an internship in the Chicago area during the summer of > 1984. They were using an assembler with IF macros. > > On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote: > > > > HLASM in 1980? Not before June 1992. I assume that you were using XF and > H, possibly with the SLAC mods on the latter (thank you, Greg and John.) > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Donald Blake [dhbl...@gmail.com] > > Sent: Sunday, April 26, 2020 8:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: C > > > > I took my first C course in 1980. The text was the original *The C > > programming Language* by Kerrigan and Richie, which I still have on my > > shelf, The text is copyright 1978. That's 42 years ago. I was an IBM HL > > Assembler programmer at the time. BTW ... we still were using IFOX00 at > the > > time as well. > > > > > Hey, it's not politically correct to point out how old C is. > > > > > > > > > -- > > > Shmuel (Seymour J.) Metz > > > http://mason.gmu.edu/~smetz3 > > > > > > > -- > > 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 > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
thanks
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Sunday, April 26, 2020 3:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
+1
Or RTFKC:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
.cbclx01/zos_supporting_ansi_iso_standards.htm
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of retired mainframer
Sent: Sunday, April 26, 2020 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
Don't allow extraneous factors (such as optimization or argument promotions)
to obfuscate the information you want. If you want the sizes of the types,
print the sizes of the types.
#include
int main(void)
{
printf("%zd %zd %zd", sizeof(short), sizeof(int), sizeof(long));
return 0;
}
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Joseph Reichman
> Sent: Sunday, April 26, 2020 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: XL C\C ++ sizeof of datatypes
>
> HI
>
>I am looking in the XL C docs lang reference user guide programming
guide
> For the length of the following data types
> Short , int long and I cannot seem to find it
> frustrated
>
> I coded a program
>
> Int len;
> Unsigned short shortype;
> Int len = sizeof(shorttype);
>
>But the compiler seemed to comment the above
> statement and not generate the assembler ps (I am running metal c);
>
> Any help appreciate it
--
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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C
SPPS was the language. Google can't find it but it's embedded in the 3651 store controller manuals. On Mon, Apr 27, 2020, 06:01 Wayne Bickerdike wrote: > I thought the macros were part of CONCEPT 14? I do remember working on IBM > 3684 point of sale systems between 1982 and 1986. They were programmed > using an Asembler like language called SPSS II, it had IF THEN ELSE and > other macros. > > On Mon, Apr 27, 2020, 03:36 Seymour J Metz wrote: > >> Those macros were not part of the assembler. As I recall there was a >> popular macro package called CONCEPT 101 (sp?) floating around, and another >> package called PROC, but they didn't come from IBM. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf >> of Mike Schwab [mike.a.sch...@gmail.com] >> Sent: Sunday, April 26, 2020 1:25 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: C >> >> I was doing an internship in the Chicago area during the summer of >> 1984. They were using an assembler with IF macros. >> >> On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote: >> > >> > HLASM in 1980? Not before June 1992. I assume that you were using XF >> and H, possibly with the SLAC mods on the latter (thank you, Greg and John.) >> > >> > >> > -- >> > Shmuel (Seymour J.) Metz >> > http://mason.gmu.edu/~smetz3 >> > >> > >> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >> behalf of Donald Blake [dhbl...@gmail.com] >> > Sent: Sunday, April 26, 2020 8:51 AM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: C >> > >> > I took my first C course in 1980. The text was the original *The C >> > programming Language* by Kerrigan and Richie, which I still have on my >> > shelf, The text is copyright 1978. That's 42 years ago. I was an IBM HL >> > Assembler programmer at the time. BTW ... we still were using IFOX00 at >> the >> > time as well. >> > >> > > Hey, it's not politically correct to point out how old C is. >> > > >> > > >> > > -- >> > > Shmuel (Seymour J.) Metz >> > > http://mason.gmu.edu/~smetz3 >> > > >> > >> > -- >> > 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 >> >> >> >> -- >> Mike A Schwab, Springfield IL USA >> Where do Forest Rangers go to get away from it all? >> >> -- >> 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 >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C
Wayne, I didn’t learn C or SPSS for example, learned the IBM Lang’s, Assembler, Cobol, PL/1 and FORTRAN IV and of course rexx and various other command list languages on VM and MVS. But your reference to IBM 3600 brought my past life as a VSE Sysprog we wrote 3600 replacement programs for 8100s . The environment was manufacturing and CICS , good ole younger days, thank you. Scott On Sun, Apr 26, 2020 at 4:22 PM Wayne Bickerdike wrote: > SPPS was the language. Google can't find it but it's embedded in the 3651 > store controller manuals. > > On Mon, Apr 27, 2020, 06:01 Wayne Bickerdike wrote: > > > I thought the macros were part of CONCEPT 14? I do remember working on > IBM > > 3684 point of sale systems between 1982 and 1986. They were programmed > > using an Asembler like language called SPSS II, it had IF THEN ELSE and > > other macros. > > > > On Mon, Apr 27, 2020, 03:36 Seymour J Metz wrote: > > > >> Those macros were not part of the assembler. As I recall there was a > >> popular macro package called CONCEPT 101 (sp?) floating around, and > another > >> package called PROC, but they didn't come from IBM. > >> > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> http://mason.gmu.edu/~smetz3 > >> > >> > >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf > >> of Mike Schwab [mike.a.sch...@gmail.com] > >> Sent: Sunday, April 26, 2020 1:25 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: C > >> > >> I was doing an internship in the Chicago area during the summer of > >> 1984. They were using an assembler with IF macros. > >> > >> On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote: > >> > > >> > HLASM in 1980? Not before June 1992. I assume that you were using XF > >> and H, possibly with the SLAC mods on the latter (thank you, Greg and > John.) > >> > > >> > > >> > -- > >> > Shmuel (Seymour J.) Metz > >> > http://mason.gmu.edu/~smetz3 > >> > > >> > > >> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > >> behalf of Donald Blake [dhbl...@gmail.com] > >> > Sent: Sunday, April 26, 2020 8:51 AM > >> > To: IBM-MAIN@LISTSERV.UA.EDU > >> > Subject: C > >> > > >> > I took my first C course in 1980. The text was the original *The C > >> > programming Language* by Kerrigan and Richie, which I still have on my > >> > shelf, The text is copyright 1978. That's 42 years ago. I was an IBM > HL > >> > Assembler programmer at the time. BTW ... we still were using IFOX00 > at > >> the > >> > time as well. > >> > > >> > > Hey, it's not politically correct to point out how old C is. > >> > > > >> > > > >> > > -- > >> > > Shmuel (Seymour J.) Metz > >> > > http://mason.gmu.edu/~smetz3 > >> > > > >> > > >> > -- > >> > 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 > >> > >> > >> > >> -- > >> Mike A Schwab, Springfield IL USA > >> Where do Forest Rangers go to get away from it all? > >> > >> -- > >> 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 > >> > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C
> I thought the macros were part of CONCEPT 14? CONCEPT 14 (http://skycoast.us/pscott/software/mvs/c14/c14-.html) could be what I was thinking of. It's the basis for the macro package in the HLASM Toolkit. The macro package I actually used was called PROC. > http://skycoast.us/pscott/software/mvs/c14/c14-.html The only SPSS I ever heard of was Statistical Package for the Social Sciences, and it didn't look like assembler. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Wayne Bickerdike [wayn...@gmail.com] Sent: Sunday, April 26, 2020 4:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C I thought the macros were part of CONCEPT 14? I do remember working on IBM 3684 point of sale systems between 1982 and 1986. They were programmed using an Asembler like language called SPSS II, it had IF THEN ELSE and other macros. On Mon, Apr 27, 2020, 03:36 Seymour J Metz wrote: > Those macros were not part of the assembler. As I recall there was a > popular macro package called CONCEPT 101 (sp?) floating around, and another > package called PROC, but they didn't come from IBM. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Mike Schwab [mike.a.sch...@gmail.com] > Sent: Sunday, April 26, 2020 1:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: C > > I was doing an internship in the Chicago area during the summer of > 1984. They were using an assembler with IF macros. > > On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote: > > > > HLASM in 1980? Not before June 1992. I assume that you were using XF and > H, possibly with the SLAC mods on the latter (thank you, Greg and John.) > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Donald Blake [dhbl...@gmail.com] > > Sent: Sunday, April 26, 2020 8:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: C > > > > I took my first C course in 1980. The text was the original *The C > > programming Language* by Kerrigan and Richie, which I still have on my > > shelf, The text is copyright 1978. That's 42 years ago. I was an IBM HL > > Assembler programmer at the time. BTW ... we still were using IFOX00 at > the > > time as well. > > > > > Hey, it's not politically correct to point out how old C is. > > > > > > > > > -- > > > Shmuel (Seymour J.) Metz > > > http://mason.gmu.edu/~smetz3 > > > > > > > -- > > 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 > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > 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 > -- 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: Friday OT, cheerful program for gloomy times
> Mike Cowlishaw created the Rexx language
Yes, and if you look at the article you linked to, you will see "He has
contributed to and/or edited various computing standards, including ISO (SGML,
COBOL, C, C++), BSI (SGML, C), ANSI (REXX), IETF (HTTP 1.0/RFC 1945), W3C (XML
Schema), ECMA (JavaScript/ECMAScript, C#, CLI), and IEEE (754 decimal
floating-point). "
I doubt that he would claim that the standard he worked on was the standard.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM
Poncelet [ponce...@bcs.org.uk]
Sent: Sunday, April 26, 2020 3:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times
Mike Cowlishaw created the Rexx language
https://secure-web.cisco.com/1wHB0OokqTuD1qCScSXs4vR7WnmA1aaX4xY-RDe3iultGsGFW_EievpsqsLeqREtY7OMbYCI4fR2vRtHuiJBMAB54rDjknPMMRWKLZDzBB-eUsT5ekPkHDrGpMlAkrnPtHb4VklYeecMBEtsNkV-OBz9Tw5z4tWrAvfP1NnTUbx-unParojR5d0_Xfxp0NaFNp0x760nqXgkUkxzXDDR89eqE4ZdtPnAjD4z0oBAx3sPct9_KvjZEz6kFgU6kbGRXldrUl7ZbMG9Vm0CTdsT9_wMAIt3MO-9efLINUKHCRrn_yp1mQ_KHYBgZzr8pwNsrhpyasbuWzJQ_SI2SIM2xLf87UvB8ks78AYRd-gSbp14-Q-YdaPhLW0iF7Wz-FGyudvxjxyBinuLwPVfO-haEjGKSVJ9Ya0qI-VeF1UKsvbZT_AvDY4XzIUiOBxz9VvJ3/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMike_Cowlishaw
On 26/04/2020 15:48, Paul Gilmartin wrote:
> On Sun, 26 Apr 2020 07:39:27 +, Seymour J Metz wrote:
>
>> They say that the memory is the second thing to go; I don't remember the
>> first thing.
>>
>> Given that Mike Cowlishaw was involved in developing ANSI X3.274-1996, I'm
>> pretty sure that he would claim that to be the standard Rexx language, just
>> as I'm pretty sure that John Backus would consider X3.9-1966, X3.9-1978,
>> etc., to be standard Fortran, not what ran on the 704.
>>
> I find this akin to expecting all software to follow the antiquated
> MSDOS 8.3 filename format convention.
>
>>
>> From: CM Poncelet
>> Sent: Saturday, April 25, 2020 11:40 PM
>>
>> "ON NO VALUE" from memory.
>>
> At one time, IBM's Rexx compiler considered SIGNAL ON NOVALUE (sic) a
> syntax error if the label was not supplied. I think it got better shortly.
>
>> "supports the standard Rexx language" as per Mike Cowlishaw's definition
>> (COW).
>>
>> Comparison of Built-In Functions
>>
>> The following table provides a comparison of Built-In Functions
>> for VM/SP CMS REXX (CMS), M.F. Cowlishaw's definition (COW),
>> Systems Application Architecture Procedures Language (SAA), and
>> CTC REXX.
>>
>> Table 3. Comparison of Built-in Functions
>>
>>
>> Availability of Built-in Functions
>>
>> FunctionSAA COW CMS CTC
>>...
>> CHARINx x - x
>> CHAROUT x x - x
>> CHARS x x - x
>> ...
>> DATE x x x x
>> ...
> But no discussion of supported operand formats.
>
>> LINEINx x - x
>> LINEOUT x x - x
>>...
>> STREAMx - - x
>>...
> CMS Rexx has supported the *standard* stream I/O for many releases.
>
> Where does one find SAA nowadays. Mostly, I remember its incursion
> was disruptive by scrambling ISPF's familiar PF key assignments.
>
See below for the SPF/PC standard Rexx one.
> I don't believe SPF/PC governs the standard for either Rexx or Java.
>
>>> DATE('B',foo,'S') is valid in standard Rexx. I don't believe that the first
>>> and third
>>> parameters are allowed to be longer than 1 character.
>>>
> They're truncated. Characters beyond the initial are irrelevant.
>
>
>>> From: CM Poncelet
>>> Sent: Saturday, April 25, 2020 7:10 PM
>>>
>>> Have you checked that your version works, other than on a mainframe?
>>>
> Regina, yes.
>
>>> SPF/PC Rexx supports the standard Rexx language, but not the full IBM
>>> REXX (which includes EXECIO etc.) and it does not recognise your format
>>> of DATE parms. ...
>>>
> SPF/PC, perhaps; standard, no.
>
> -- gil
>
> --
> 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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Request: Examples of an IPCS RUNARRAY command where the EXEC clause display storage using a pointer as a displacement off of X
Is it failing even when everything is in the same address space? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Binyamin Dissen [bdis...@dissensoftware.com] Sent: Sunday, April 26, 2020 9:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Request: Examples of an IPCS RUNARRAY command where the EXEC clause display storage using a pointer as a displacement off of X I would like to see an examples of an IPCS RUNARRAY command where the EXEC clause display storage using a pointer as a displacement off of X. So far I have not been able to make it work. -- Binyamin Dissen http://secure-web.cisco.com/1JFmpAbJmE5_jVmtH7wbw_DccdkBCIp2LZ6HEsiSUraRg1_paQKA5lXs4hWnzHfEH6t_F4JqszoeDVu6bcyHjzdpSUm_dkheCNS7o5neoftR3yUgi86-16Fo2lJVMDHHjkBabpmLy12FOc0vP7O2btu_w7-73Le8Fb4JLgBcTxO4mCmFhoH7poK303z6p3juDclPiQ3hjulRo_xF3EDbep8zP9MZIJXncB0IEGqXHSp_5Wg4dI14nk0foTxaf37UAwPxraU96RY9SjuD_oTu9FBaYtCMfj6-nzvO9IEMGlVsZpySV1QeQeqv7PFza-_W65hpRUg_LQCHFBbxY_owopTmZznSx6DuO09ZdJGbcBLZp7CsPXpc8e68VlGDOJ8kBRPegL8KKJpEbgSJE1oQGXdjhShhVToWnCBQv2JS57z1bnzM4hPI09b_allZRxa_x/http%3A%2F%2Fwww.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: XL C\C ++ sizeof of datatypes
On Sun, 26 Apr 2020 12:58:57 -0700, Charles Mills wrote: >+1 > >Or RTFKC: >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbclx01/zos_supporting_ansi_iso_standards.htm > Where I read: Equivalent type of char: signed char, unsigned char, or user-defined: The default for char is unsigned My experience, long ago, is that these are distinct types: C/C++ reported a syntax error for formal parameter (char *), actual parameter (unsigned char * ). It's not what it means; it's what it's called. Sequence of white-space characters (excluding the new-line): Any spaces or comments in the source program are interpreted as one space. This may have some contention with historic use of comments as concatenators. E.g. something like writing foo/* */bar for foobar. The result of converting an integer from a shorter signed integer: The lowest 2 bytes of the integer are used to represent the short int. ??? I'd expect sign extension. But wasn't there a transition from unsigned-preserving to value-preserving. E.g.: K: -1 > (unsigned) 0 ANSI: -1 < (unsigned) 0 CDC (not IBM) 3600 and earlier 1604 were wretched hybrids. Numeric arithmetic was 1's complement; addressing arithmetic was 2's complement. And CDC 6600 had no compare instruction. FORTRAN compared integers by subtracting (hardware didn't report overflow) and testing the sign of the result. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
In article <006301d61bd2$bf391680$3dab4380$@gmail.com> you wrote: > HI >I am looking in the XL C docs lang reference user guide programming guide > For the length of the following data types > Short , int long and I cannot seem to find it > frustrated > I coded a program > Int len; > Unsigned short shortype; > Int len = sizeof(shorttype); > >But the compiler seemed to comment the above statement > and not generate the assembler ps (I am running metal c); > Any help appreciate it It depends. For 31-bit, it's ILP32, for 64-bit, it's LP64. See: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.cbcpx01/datatypesize64.htm (short is always 2 bytes. SAS/C uses the same scheme.) -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
Without testing, I think that a signed char argument satisfies and unsigned char formal parameter, but that char does not satisfy unsigned char *. There is some C messiness around char signage. I think on most platforms char is kind of the same as signed char, but not exactly the same. On Z a char is kind of the same as an unsigned char, but not exactly the same. I am obviously fuzzy on the exact details, and no doubt someone will be happy to set me straight. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, April 26, 2020 2:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XL C\C ++ sizeof of datatypes On Sun, 26 Apr 2020 12:58:57 -0700, Charles Mills wrote: >+1 > >Or RTFKC: >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbclx01/zos_supporting_ansi_iso_standards.htm > Where I read: Equivalent type of char: signed char, unsigned char, or user-defined: The default for char is unsigned My experience, long ago, is that these are distinct types: C/C++ reported a syntax error for formal parameter (char *), actual parameter (unsigned char * ). It's not what it means; it's what it's called. Sequence of white-space characters (excluding the new-line): Any spaces or comments in the source program are interpreted as one space. This may have some contention with historic use of comments as concatenators. E.g. something like writing foo/* */bar for foobar. The result of converting an integer from a shorter signed integer: The lowest 2 bytes of the integer are used to represent the short int. ??? I'd expect sign extension. But wasn't there a transition from unsigned-preserving to value-preserving. E.g.: K: -1 > (unsigned) 0 ANSI: -1 < (unsigned) 0 CDC (not IBM) 3600 and earlier 1604 were wretched hybrids. Numeric arithmetic was 1's complement; addressing arithmetic was 2's complement. And CDC 6600 had no compare instruction. FORTRAN compared integers by subtracting (hardware didn't report overflow) and testing the sign of the result. -- gil -- 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: XL C\C ++ sizeof of datatypes
Actually, on the 3600 you could select whether indexing was 1s' complement or 2' complement. I had lust in my heart for that machine and its big brother, the 3800. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Sunday, April 26, 2020 5:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XL C\C ++ sizeof of datatypes On Sun, 26 Apr 2020 12:58:57 -0700, Charles Mills wrote: >+1 > >Or RTFKC: >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbclx01/zos_supporting_ansi_iso_standards.htm > Where I read: Equivalent type of char: signed char, unsigned char, or user-defined: The default for char is unsigned My experience, long ago, is that these are distinct types: C/C++ reported a syntax error for formal parameter (char *), actual parameter (unsigned char * ). It's not what it means; it's what it's called. Sequence of white-space characters (excluding the new-line): Any spaces or comments in the source program are interpreted as one space. This may have some contention with historic use of comments as concatenators. E.g. something like writing foo/* */bar for foobar. The result of converting an integer from a shorter signed integer: The lowest 2 bytes of the integer are used to represent the short int. ??? I'd expect sign extension. But wasn't there a transition from unsigned-preserving to value-preserving. E.g.: K: -1 > (unsigned) 0 ANSI: -1 < (unsigned) 0 CDC (not IBM) 3600 and earlier 1604 were wretched hybrids. Numeric arithmetic was 1's complement; addressing arithmetic was 2's complement. And CDC 6600 had no compare instruction. FORTRAN compared integers by subtracting (hardware didn't report overflow) and testing the sign of the result. -- gil -- 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: XL C\C ++ sizeof of datatypes
First of all, char in C is a subtype of int,
which means that you can do normal arithmetic operations to chars
and that chars are allowed in int expressions without special action
needed.
for example:
char c;
c = 'A' + 1; /* c will be 'B' */
c = c - 'A' + 'a'; /* c will now be 'b' - lower case */
Compare this to Pascal for example, where char and integer are two
different and
incompatible types. To do the same as above in Pascal, you need
conversion functions
(which are part of the Pascal standard):
var c: char;
c := chr (ord ('A') + 1);
c := chr (ord (c) - ord ('A') + ord ('a'));
Back to C:
Now, because chars are small ints in C (much like shorts), they can of
course be signed or unsigned.
If we have 8 bit bytes (which is normal on today's machines, but C would
of course support other
architectures, too), the ranges are -128 .. 127 for signed char (2's
complement) and 0 .. 255 for unsigned char.
If you code
char c;
like in the example above, the char is always signed or unsigned
depending on the default
active during compilation (can probably be modified by compiler option;
if not, there will
be a "factory" setting).
This "factory" setting is unsigned for IBMs z/OS compilers, and signed
for most Windows
and Unix compilers I am aware of.
The reason may be the EBCDIC character set; if signed were used with
EBCDIC, all the
normal characters and digits (X'C1' = 'A', X'F0' = '0') would have
negative char values.
So in my opinion the choice of the unsigned char default is natural for
EBCDIC machines.
The difference between this default has some implications for programs
that want to run
on both platforms (mainframe and PC, for example). I usually cope with
this by explicitly
specifying unsigned char, wherever necessary (only at places, where
computing is done
with character values, for example, when doing hexadecimal output of
storage areas
on both platforms).
BTW: if you want to take a closer look at Pascal, you can find the New
Stanford Pascal Compiler here:
http://bernd-oppolzer.de/job9.htm
https://github.com/StanfordPascal
https://www.facebook.com/StanfordPascal
which runs on IBM Mainframes (MVS and CMS) and on Windows, Unix (Linux),
OS/2, MacOS etc.;
on the Mainframe, 370 machine code is generated. On the other platforms,
the generated P-Code
is interpreted. The P-Code interpreter PCINT is written in C and (of
course) has to use unsigned chars
to implement the P-instructions in exactly the same way as they are
compiled on the mainframe.
Kind regards
Bernd
Am 26.04.2020 um 23:44 schrieb Charles Mills:
Without testing, I think that a signed char argument satisfies and unsigned char
formal parameter, but that char does not satisfy unsigned char *.
There is some C messiness
https://www.facebook.com/StanfordPascal/?eid=ARDEjQaZgVZL2fivkB0AXGk_-mZF97XV3mESzaJ0RR-2NKu0jyroGwFbXt9kqk5UUIUCiHV9d0w2XcfUaround
char signage. I think on most platforms char is kind of the same as signed
char, but not exactly the same. On Z a char is kind of the same as an unsigned
char, but not exactly the same. I am obviously fuzzy on the exact details, and
no doubt someone will be happy to set me straight.
Charles
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
On Mon, 27 Apr 2020 03:49:00 +0200, Bernd Oppolzer wrote: >First of all, char in C is a subtype of int, >which means that you can do normal arithmetic operations to chars >and that chars are allowed in int expressions without special action >needed. > >for example: > >char c; > >c = 'A' + 1; /* c will be 'B' */ >c = c - 'A' + 'a'; /* c will now be 'b' - lower case */ > Agreed. Yet no such compatibility exists among unsigned char *, signed char *, and char*. However, many implementations quietly ignore violations of this. I encountered this on IBM mainframe when a FOSS program attempted to call a (standard, such as strlen()?) function expecting a char * argument with an unsigned char *. The intrinsic type of "XYZ" here is char *, not unsigned char *, and surely not signed char *. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C
Seymour, The assembler was SPPS. Too close to the stats package name SPSS. I was working at a DOS/VSE shop in England in 1983 and they had COBOL and SPPS on their IBM cash registers. I had neither mainframe COBOL nor SPPS skills but I'd written a whole bunch of Microfocus COBOL on CP/M micros. I convinced them that I could do mainframe COBOL, which wasn't that difficult. When I looked at the SPPS code, it was macro Assembler, so that was the start of a short time with same. A few years later I found myself in Melbourne, Australia working for a department store. They also had 3651 store controllers and 36.. POS terminals (point of sale LOL). The 3651 implemented a local area network before I'd seen what we know now as LAN. Connected to a FEP, it was quite smart in its day. The PC killed off this technology and within a few years most of this type of kit was on the scrap heap. On Mon, Apr 27, 2020 at 6:46 AM Seymour J Metz wrote: > > I thought the macros were part of CONCEPT 14? > > CONCEPT 14 (http://skycoast.us/pscott/software/mvs/c14/c14-.html) > could be what I was thinking of. It's the basis for the macro package in > the HLASM Toolkit. > > The macro package I actually used was called PROC. > > > http://skycoast.us/pscott/software/mvs/c14/c14-.html > > The only SPSS I ever heard of was Statistical Package for the Social > Sciences, and it didn't look like assembler. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Wayne Bickerdike [wayn...@gmail.com] > Sent: Sunday, April 26, 2020 4:01 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: C > > I thought the macros were part of CONCEPT 14? I do remember working on IBM > 3684 point of sale systems between 1982 and 1986. They were programmed > using an Asembler like language called SPSS II, it had IF THEN ELSE and > other macros. > > On Mon, Apr 27, 2020, 03:36 Seymour J Metz wrote: > > > Those macros were not part of the assembler. As I recall there was a > > popular macro package called CONCEPT 101 (sp?) floating around, and > another > > package called PROC, but they didn't come from IBM. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > > of Mike Schwab [mike.a.sch...@gmail.com] > > Sent: Sunday, April 26, 2020 1:25 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: C > > > > I was doing an internship in the Chicago area during the summer of > > 1984. They were using an assembler with IF macros. > > > > On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote: > > > > > > HLASM in 1980? Not before June 1992. I assume that you were using XF > and > > H, possibly with the SLAC mods on the latter (thank you, Greg and John.) > > > > > > > > > -- > > > Shmuel (Seymour J.) Metz > > > http://mason.gmu.edu/~smetz3 > > > > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > > behalf of Donald Blake [dhbl...@gmail.com] > > > Sent: Sunday, April 26, 2020 8:51 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: C > > > > > > I took my first C course in 1980. The text was the original *The C > > > programming Language* by Kerrigan and Richie, which I still have on my > > > shelf, The text is copyright 1978. That's 42 years ago. I was an IBM HL > > > Assembler programmer at the time. BTW ... we still were using IFOX00 at > > the > > > time as well. > > > > > > > Hey, it's not politically correct to point out how old C is. > > > > > > > > > > > > -- > > > > Shmuel (Seymour J.) Metz > > > > http://mason.gmu.edu/~smetz3 > > > > > > > > > > -- > > > 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 > > > > > > > > -- > > Mike A Schwab, Springfield IL USA > > Where do Forest Rangers go to get away from it all? > > > > -- > > 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 > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to
Re: C
SPPS reminds of a little war story. The garment retailer had a ticketing system whereby we printed sticky labels, numbered in 100 increments. That's what the analyst specified. These labels were quite expensive compared to line printer paper. They were printed on the 1403 or whatever. We ran a few thousand off and the analyst realised that he should have said increments of 10, not 100. We were going to run out of numbers. Lots of useless labels and red faces On Mon, Apr 27, 2020 at 3:06 PM Wayne Bickerdike wrote: > Seymour, > > The assembler was SPPS. Too close to the stats package name SPSS. > > I was working at a DOS/VSE shop in England in 1983 and they had COBOL and > SPPS on their IBM cash registers. > > I had neither mainframe COBOL nor SPPS skills but I'd written a whole > bunch of Microfocus COBOL on CP/M micros. > > I convinced them that I could do mainframe COBOL, which wasn't that > difficult. When I looked at the SPPS code, it was macro Assembler, so that > was the start of a short time with same. > > A few years later I found myself in Melbourne, Australia working for a > department store. They also had 3651 store controllers and 36.. POS > terminals (point of sale LOL). > The 3651 implemented a local area network before I'd seen what we know now > as LAN. Connected to a FEP, it was quite smart in its day. The PC killed > off this technology and within a few years most of this type of kit was on > the scrap heap. > > > > > On Mon, Apr 27, 2020 at 6:46 AM Seymour J Metz wrote: > >> > I thought the macros were part of CONCEPT 14? >> >> CONCEPT 14 (http://skycoast.us/pscott/software/mvs/c14/c14-.html) >> could be what I was thinking of. It's the basis for the macro package in >> the HLASM Toolkit. >> >> The macro package I actually used was called PROC. >> >> > http://skycoast.us/pscott/software/mvs/c14/c14-.html >> >> The only SPSS I ever heard of was Statistical Package for the Social >> Sciences, and it didn't look like assembler. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf >> of Wayne Bickerdike [wayn...@gmail.com] >> Sent: Sunday, April 26, 2020 4:01 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: C >> >> I thought the macros were part of CONCEPT 14? I do remember working on IBM >> 3684 point of sale systems between 1982 and 1986. They were programmed >> using an Asembler like language called SPSS II, it had IF THEN ELSE and >> other macros. >> >> On Mon, Apr 27, 2020, 03:36 Seymour J Metz wrote: >> >> > Those macros were not part of the assembler. As I recall there was a >> > popular macro package called CONCEPT 101 (sp?) floating around, and >> another >> > package called PROC, but they didn't come from IBM. >> > >> > >> > -- >> > Shmuel (Seymour J.) Metz >> > http://mason.gmu.edu/~smetz3 >> > >> > >> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >> behalf >> > of Mike Schwab [mike.a.sch...@gmail.com] >> > Sent: Sunday, April 26, 2020 1:25 PM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Re: C >> > >> > I was doing an internship in the Chicago area during the summer of >> > 1984. They were using an assembler with IF macros. >> > >> > On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote: >> > > >> > > HLASM in 1980? Not before June 1992. I assume that you were using XF >> and >> > H, possibly with the SLAC mods on the latter (thank you, Greg and John.) >> > > >> > > >> > > -- >> > > Shmuel (Seymour J.) Metz >> > > http://mason.gmu.edu/~smetz3 >> > > >> > > >> > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >> > behalf of Donald Blake [dhbl...@gmail.com] >> > > Sent: Sunday, April 26, 2020 8:51 AM >> > > To: IBM-MAIN@LISTSERV.UA.EDU >> > > Subject: C >> > > >> > > I took my first C course in 1980. The text was the original *The C >> > > programming Language* by Kerrigan and Richie, which I still have on my >> > > shelf, The text is copyright 1978. That's 42 years ago. I was an IBM >> HL >> > > Assembler programmer at the time. BTW ... we still were using IFOX00 >> at >> > the >> > > time as well. >> > > >> > > > Hey, it's not politically correct to point out how old C is. >> > > > >> > > > >> > > > -- >> > > > Shmuel (Seymour J.) Metz >> > > > http://mason.gmu.edu/~smetz3 >> > > > >> > > >> > > -- >> > > 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 >> > >> > >> > >> > -- >> > Mike A Schwab,
Re: SP macros
The structured programming macros originated from IBM Federal Systems Division and were called "Concept 14", freely available at the time. Many variants were created in subsequent years, both within IBM and in the mainframe open source community of the 1970's. IBM going to OCO impacted their development and adoption. On Mon, Apr 27, 2020 at 4:19 AM Bernd Oppolzer wrote: > We had a similar package of SP (structured programming) macros in Germany, > very powerful (IF...THEN...ELSE...EIF, LOOP WHILE/UNTIL...ELOOP etc.). > Most interesting: there were always multiple conditions on IF and LOOP, > separated by asterisks, so > IF...THEN(1)...THEN(2)...THEN(3)...ELSE...EIF in fact was more a CASE > (or SWITCH) statement > and LOOP WHILE ... OUT(1)...OUT(2)...OUT(3)...ELOOP was very powerful, too > (and there was BREAK, too, of course). Some macros even supported > procedure blocks > with separate base registers, which allowed very large programs using > only two or four > base registers, if used correctly. > > The SP macros are still in use at different large mainframe users in > Germany; > when I started work at Allianz Versicherung (insurance) in 1990 ca., I > was told that they > originated from Quelle Versandhaus (mail order company, bankrupt in 2009), > but I am not sure about that. My first task at Allianz was to teach > ASSEMBLER to some 15 newbies, > and of course I had to teach the SP macros, too (every new program had > to make use of them, > the use of normal branch operations was forbidden). In 2014, I changed > the SP macros at Allianz Versicherung > to generate relative branches and support baseless coding, which was > about the last project I did there. > > Kind regards > > Bernd > > > Am 26.04.2020 um 19:35 schrieb Seymour J Metz: > > Those macros were not part of the assembler. > > As I recall there was a popular macro package called CONCEPT 101 (sp?) > floating around, > > and another package called PROC, but they didn't come from IBM. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Mike Schwab [mike.a.sch...@gmail.com] > > Sent: Sunday, April 26, 2020 1:25 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: C > > > > I was doing an internship in the Chicago area during the summer of > > 1984. They were using an assembler with IF macros. > > > > -- > 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: XL C\C ++ sizeof of datatypes
Am 27.04.2020 um 04:21 schrieb Paul Gilmartin:
On Mon, 27 Apr 2020 03:49:00 +0200, Bernd Oppolzer wrote:
First of all, char in C is a subtype of int,
which means that you can do normal arithmetic operations to chars
and that chars are allowed in int expressions without special action
needed.
for example:
char c;
c = 'A' + 1; /* c will be 'B' */
c = c - 'A' + 'a'; /* c will now be 'b' - lower case */
Agreed. Yet no such compatibility exists among unsigned char *,
signed char *, and char*. However, many implementations quietly
ignore violations of this. I encountered this on IBM mainframe when
a FOSS program attempted to call a (standard, such as strlen()?)
function expecting a char * argument with an unsigned char *.
The intrinsic type of "XYZ" here is char *, not unsigned char *, and
surely not signed char *.
Yes,
the compiler flags functions calls where unsigned char * arguments (for
example)
are passed to char * parameters, even if the default signage for char is
unsigned -
usually a warning. There is in fact no difference between the types on
z/OS (given the
unsigned default), but there would be a difference when compiled on
other platforms.
The compiler issues the warning anyway. Of course, you can ignore such
warnings.
AFAIK, the ANSI functions like strlen, strcmp etc. have char *
parameters (no signage specified),
so the problem arises if you pass unsigned char pointers or arrays to
them. The problem IMO
would also occur, if you would pass explicitly signed char pointers or
arrays.
You can get rid of the warnings by casting your arguments:
x = strlen ((char *) my_unsigned_string);
OTOH, if you write own functions which must process a passed string as a
string of
unsigned chars, you cass pass it as char * and cast it inside, that is:
int myfunc (char *str)
{
unsigned char *ustr = (unsigned char *) str;
/* now work with ustr instead of str */
...
}
HTH, 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: XL C\C ++ sizeof of datatypes
K did not require char to be at least 8 bits, but ANSI did.
I wonder what C did on a ones' complement machine if a string contained a -0
character?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Sunday, April 26, 2020 9:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
First of all, char in C is a subtype of int,
which means that you can do normal arithmetic operations to chars
and that chars are allowed in int expressions without special action
needed.
for example:
char c;
c = 'A' + 1; /* c will be 'B' */
c = c - 'A' + 'a'; /* c will now be 'b' - lower case */
Compare this to Pascal for example, where char and integer are two
different and
incompatible types. To do the same as above in Pascal, you need
conversion functions
(which are part of the Pascal standard):
var c: char;
c := chr (ord ('A') + 1);
c := chr (ord (c) - ord ('A') + ord ('a'));
Back to C:
Now, because chars are small ints in C (much like shorts), they can of
course be signed or unsigned.
If we have 8 bit bytes (which is normal on today's machines, but C would
of course support other
architectures, too), the ranges are -128 .. 127 for signed char (2's
complement) and 0 .. 255 for unsigned char.
If you code
char c;
like in the example above, the char is always signed or unsigned
depending on the default
active during compilation (can probably be modified by compiler option;
if not, there will
be a "factory" setting).
This "factory" setting is unsigned for IBMs z/OS compilers, and signed
for most Windows
and Unix compilers I am aware of.
The reason may be the EBCDIC character set; if signed were used with
EBCDIC, all the
normal characters and digits (X'C1' = 'A', X'F0' = '0') would have
negative char values.
So in my opinion the choice of the unsigned char default is natural for
EBCDIC machines.
The difference between this default has some implications for programs
that want to run
on both platforms (mainframe and PC, for example). I usually cope with
this by explicitly
specifying unsigned char, wherever necessary (only at places, where
computing is done
with character values, for example, when doing hexadecimal output of
storage areas
on both platforms).
BTW: if you want to take a closer look at Pascal, you can find the New
Stanford Pascal Compiler here:
http://secure-web.cisco.com/1ahRAh4N0CSp3gLQZrp-JRlfXHuhuDJQujTXuyt8e3kumDDxT7dDKWO8t8_IBUAYCYZyLxfUBnwWz9AwzGhs7pY99lm_vNvygdilxhlMNOGtSdRImFi-xm9IBnOx249ReXimPEwcmty0CAqDG3LMdyV9rMaKo-Iv6I982Iy_puqJIAAg5OO6aYswgnuVKyNZ3-XRvrm13YGxgkUS0BVP-QPOak9ypU0Mg-1GGxrp8AAw-cmYOzTzNSk1c_pthmqWbtIXAbkgZ7QL5WWm1u6ps0HyKQtC1KIcOviAiEtwR0GSGLBjtDt6kpRT6CFLbkpoP3P6vsM-LLTCKUDcOtsIvCRjbzx1jVP2Creo15L8gE2UoLsF9Dkp23xyAd_wjsHmjgp42wVi8QP-6Rl3jBZkMr519keflDI1nK_klJsTCBzzRjxn3gFq4y2NUyLS6P8rM/http%3A%2F%2Fbernd-oppolzer.de%2Fjob9.htm
https://secure-web.cisco.com/1hHx-M_IeANqdDOt3iYTGkb4FtQQe_aZgDhl66rbSBupoailYOTGHN-d9MY51K9niLKgvpdPWdlhUWsbFRry3TkOzXNALYs_fgVIhkeFhhOEtCUyFdrUT-6IigbGf61pRlye3y62ZlCvF7jlgtoXJvooyUG-uH5Cy9NheskLIXVad3akNA0pg4VqMCIdmPWoDWnbeClK9iq55QfVAi5ixx5NjHqCwUNmh3S8e2eivPmMUhQivNqmLO5JvVehmJAQKf1GjVLhc4k_HGxo7_9_wawW_D0z5nslZSmuBkIKyRxS0pCpvvOFr12jWiuGi6UzKrfaddOW8u62cFsvQUDWbsWO3NaCnz88FwpI4gYJZKR6O1VojfhyTELYB-5sYijvxjvkxBc3kEuz2tVGEwQxiv7ZDBKk11hab85IkWTKha9AWUC_Cc1ylxbj6421yHtcc/https%3A%2F%2Fgithub.com%2FStanfordPascal
https://www.facebook.com/StanfordPascal
which runs on IBM Mainframes (MVS and CMS) and on Windows, Unix (Linux),
OS/2, MacOS etc.;
on the Mainframe, 370 machine code is generated. On the other platforms,
the generated P-Code
is interpreted. The P-Code interpreter PCINT is written in C and (of
course) has to use unsigned chars
to implement the P-instructions in exactly the same way as they are
compiled on the mainframe.
Kind regards
Bernd
Am 26.04.2020 um 23:44 schrieb Charles Mills:
> Without testing, I think that a signed char argument satisfies and unsigned
> char formal parameter, but that char does not satisfy unsigned char *.
>
> There is some C messiness
> https://www.facebook.com/StanfordPascal/?eid=ARDEjQaZgVZL2fivkB0AXGk_-mZF97XV3mESzaJ0RR-2NKu0jyroGwFbXt9kqk5UUIUCiHV9d0w2XcfUaround
> char signage. I think on most platforms char is kind of the same as signed
> char, but not exactly the same. On Z a char is kind of the same as an
> unsigned char, but not exactly the same. I am obviously fuzzy on the exact
> details, and no doubt someone will be happy to set me straight.
>
> Charles
--
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,
Re: XL C\C ++ sizeof of datatypes
I would like to add:
as explained, the types integer and char are incompatibel in Pascal.
Furthermore, char in Pascal is NOT a computational type; you cannot do
arithmetic with chars, and there is no sign with chars (much the same as
in PL/1,
for example). To do arithmetic with chars, you need the conversion
functions ORD and CHR.
This all seems quite natural to me; the C idea that chars are small
integers and therefore have
a sign is strange IMO.
On the other hand, Pascal supports ANY standard or scalar or subrange
type as index type
for arrays, for example:
var howoften : array [char] of integer ;
ch: char;
...
read (ch);
howoften [ch] := howoften [ch] + 1;
the array howoften is used to count the occurence of chars in an input
file, for example.
And: if you want to have small integers (1 byte size), Pascal supports
them, too (with subranges):
type byte = - 128 .. 127;
var x : byte;
if your compiler, supports this, the variable x will use 1 byte and
allow normal integer arithmetic.
Kind regards
Bernd
Am 27.04.2020 um 03:49 schrieb Bernd Oppolzer:
Compare this to Pascal for example, where char and integer are two
different and
incompatible types. To do the same as above in Pascal, you need
conversion functions
(which are part of the Pascal standard):
var c: char;
c := chr (ord ('A') + 1);
c := chr (ord (c) - ord ('A') + ord ('a'));
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
On Mon, 27 Apr 2020 04:23:49 +0200, Bernd Oppolzer wrote: >I would like to add: > >as explained, the types integer and char are incompatibel in Pascal. >Furthermore, char in Pascal is NOT a computational type; you cannot do >arithmetic with chars, and there is no sign with chars (much the same as >in PL/1, >for example). To do arithmetic with chars, you need the conversion >functions ORD and CHR. > But pred() and succ() operate on any ordinal type. >This all seems quite natural to me; the C idea that chars are small >integers and therefore have a sign is strange IMO. > UCSD Pascal introduced a strange convention. AND and OR operated bitwise on 16-bit boolean operands. ODD() simply returned its 16-bit argument, unmasked, and ORD(boolean) did likewise. IF tested only the lowest bit, so it interacted properly with ODD. But I encountered a problem when I used ARRAY [BOOLEAN] and used the value of ODD(integer) as a subscript. Apple patched the problem by masking when a boolean was used as a subscript. But this left misbehaviors such as ORD(ODD(2))>ORD(ODD(1)) >On the other hand, Pascal supports ANY standard or scalar or subrange >type as index type >for arrays, for example: > >var howoften : array [char] of integer ; > ch: char; >... >read (ch); >howoften [ch] := howoften [ch] + 1; > >the array howoften is used to count the occurence of chars in an input >file, for example. > But can you use a char as a control variable of DO to step through the howoften array? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
On Mon, 27 Apr 2020 03:35:46 +, Seymour J Metz wrote: >K did not require char to be at least 8 bits, but ANSI did. > >I wonder what C did on a ones' complement machine if a string contained a -0 >character? > POSIX specifies that the component characters should be compared as if unsigned. Grrr. Pascal on CDC 6600 (its birthplace) had the idiosyncratic type ALFA, a 60-bit word containing ten 6-bit characters. Comparison operators on ALFAs treated then as 60-bit signed integers. 6600 had no hardware compare instruction, so relational operators on ALFAs did a (ones-complement) subtraction and checked the sign. My co-worker complained to Wirth, I don't know with what effect. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
