Re: PL/I Integer arithmetic
- Original Message - From: "Seymour J Metz" Sent: Thursday, September 10, 2020 1:02 AM You did, in the comment. No I didn't. You misread it. From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Wednesday, September 9, 2020 11:00 AM On 2020-09-10 00:33, Seymour J Metz wrote: Since when is 1.33... an integer? Who said it was? A/B (both integers with values 4 and 3 respectively), yield exactly 1. From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Wednesday, September 9, 2020 10:08 AM From: "Seymour J Metz" Sent: Monday, September 07, 2020 4:13 PM PL/I has never had integers. It always has had integers. The arithmetic rules for scaled fixed point are different from those for integers. In integer arithmetic, (4/3)*6 is 6 That's not the result you get in PL/I. Yes it is, with declarations as shown, as I said before, . Under IBM rules: %PROCESS RULES(IBM); INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ -- 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 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX true/false (was Constant Identifiers)
Yes. My post-grad thesis was on PL/I - and on its being originally called Fortran VI in 1962, then NPL in '64, then distributed as PL/I in '66 together with OS/360. I wrote PL/I before Clist/CLIST and long before REXX. Confused am I? On 09/09/2020 05:49, Seymour J Metz wrote: > Have you ever heard of PL/I? Much of the syntax of REXX derives from PL/I, > and it has two different string types: CHARACTER and BIT. > > With regard to the built in functions, you are once again confusing the type > of a variable with its contents. Would you argue that +1 in -1 are different > data types because one is a valid input to sqrt and the other is not? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf of > CM Poncelet > Sent: Tuesday, September 8, 2020 7:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: REXX true/false (was Constant Identifiers) > > Mr Bridges, > > 1) The reason the program does not abend is it has a "SIGNAL ON SYNTAX > NAME ERROR3" coded before the "IF TRUE THEN...", which traps the abend > and resumes execution at label ERROR3. > > 2) I disagree with Mr Metz on the grounds that he argues that > "everything in REXX is a character string" - upon which I then > implicitly ask, "What is a non-character string and in what 3GL, 2GL, > 1GL language (but not 0GL, as that would be microcode) do such > non-character strings exist that do not exist in REXX?" > > It has nothing to do with EBCDIC and ASCII. It is that REXX supports all > binary strings - as in the REXX functions C2D, C2X, D2X, X2B, B2X, > BITAND, BITOR, BITXOR etc. and as applied in reading/processing > unformatted 'raw' system dumps. To argue that "everything in REXX is a > character string"is meaningless. It might be appropriate to argue that > "everything in REXX is a binary string", as that would include > "character string" - or even "everything in REXX is a string", because > that would be sufficient in itself and would not constrain all REXX > strings to have to be "character" ones. As I said, REXX supports all > binary strings - not only "character" ones. > > Not sure whether that answers your questions, but I hope it does. > > Cheers, Chris Poncelet (retired sysprog) > > > On 08/09/2020 16:27, Bob Bridges wrote: >> Mr Poncelet, I'm interested in this example. Two questions: >> >> 1) Once TRUE is set to a '1'b in the last two sections, why does the program >> not abend when it encounters "IF TRUE THEN..."? Seems to me REXX should >> complain that TRUE is not 1 or 0. >> >> 2) From your preceding posts I got the impression you were disagreeing with >> Mr Metz, that you believed REXX represented data in other forms that EBCDIC >> character strings. (EBCDIC in TSO REXX, that is; I'm not concerned with >> ASCII platforms here.) But your example seems to support his assertion. >> Did I misunderstand you? What am I missing? >> >> --- >> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 >> >> /* This is how sin happens. We don't set out to do something very wrong. We >> make up stories that sound good to ourselves about how the thing really >> isn't that wrong, or how it really isn't anybody else's business. / Before >> we lie to others, we lie to ourselves. Do that, and it can be hard to find >> the truth again, even when it is obvious nothing but the truth will do. >> -Maggie Gallagher, 2001-08-27 */ >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of CM Poncelet >> Sent: Monday, September 7, 2020 22:33 >> >> You said, "It isn't boolean; everything in REXX is a character string." >> >> I agree that "it's all strings", but not that "everything in REXX is a >> *character* string." >> >> Try the following: >> >> ARG DEBUG >> IF ABBREV(DEBUG,D,1) THEN , >> TRACE I >> >> SIGNAL ON SYNTAX NAME ERROR0 >> TRUE = 1 >> SAY 'TRUE NUMERIC = 'TRUE >> SAY 'DATATYPE TRUE = 'DATATYPE(TRUE) >> IF ¬TRUE THEN SAY 'NOT TRUE NUMERIC' >> IF TRUE THEN SAY 'YES, TRUE NUMERIC' >> >> ERROR0: >> SIGNAL ON SYNTAX NAME ERROR1 >> TRUE = '1' >> SAY 'TRUE CHARACTER = 'TRUE >> SAY 'DATATYPE TRUE = 'DATATYPE(TRUE) >> IF ¬TRUE THEN SAY 'NOT TRUE CHARACTER' >> IF TRUE THEN SAY 'YES, TRUE CHARACTER' >> >> ERROR1: >> SIGNAL ON SYNTAX NAME ERROR2 >> TRUE = '31'X >> SAY 'TRUE HEXADECIMAL = 'TRUE >> SAY 'DATATYPE TRUE = 'DATATYPE(TRUE) >> IF ¬TRUE THEN SAY 'NOT TRUE HEXADECIMAL' >> IF TRUE THEN SAY 'YES, TRUE HEXADECIMAL' >> >> TRUE = '00110001'B >> SAY 'TRUE BINARY HEX = 'TRUE >> SAY 'DATATYPE TRUE = 'DATATYPE(TRUE) >> IF ¬TRUE THEN SAY 'NOT TRUE BINARY HEX' >> IF TRUE THEN SAY 'YES, TRUE BINARY HEX' >> >> TRUE = '0001'B >> SAY 'TRUE BINARY ONLY = 'TRUE >> SAY 'DATATYPE TRUE = 'DATATYPE(TRUE) >> IF ¬TRUE THEN SAY 'NOT TRUE BINARY ONLY' >> IF TRUE THEN SAY 'YES, TRUE BINARY ONLY' >> >> ERROR2: >> SIGNAL ON SYNTAX NAME ERROR3 >> TRUE = '1'B >> SAY 'TRUE BINARY BIT =
MVT 21.8 on a 4341 was Re: Architectural Level Sets
[Default] On 9 Sep 2020 16:16:01 -0700, in bit.listserv.ibm-main dspiegel...@hotmail.com (David Spiegel) wrote: >Hi Clark, >Did you run MVS on a 4341? >If yes, which version? Headquarters normally did our MVT sysgens for us so this was the first MVT sysgen I had done. After checking with Paul Dalman of Army Records, Rick Steffee of Naval Intelligence and Brian Scott of Volume Shoe, all of who had presented at a SHARE session on the topic, I genned 21.8 final as for a 370/158. We had lost our mod 65 due to a roof leak on Sunday so I made the phone calls on Monday just in case. Monday IBM was going to fix it. Tuesday was a different story and we got the system up by Wednesday morning. My boss and a fellow systems programmer had to learn about Unit Control Words so we could use our Comten. All in all an interesting time. Clark Morris > >Thanks and regards, >David > >On 2020-09-09 19:12, Clark Morris wrote: >> [Default] On 9 Sep 2020 14:47:15 -0700, in bit.listserv.ibm-main >> sme...@gmu.edu (Seymour J Metz) wrote: >> >>> In XA mode the problem is the SIO instruction. DOS.360, OS/360, OS/VS, etc. >>> don't support SSCH. Does OS/360 need BC when you sysgen for S/370? I'm >>> certain;ly not aware of such a dependency in OS/VS or VM. >> MVT ran on a 4341 generated as a 370/158 in my shop while we were >> upgrading to MVS. >> >> Clark Morris >> >> -- >> 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
Support for 128-bit arithmetic - was: Re: PL/I support of vector instructions?
Seymour J Metz wrote:
I was asking whether it supported vector instructions for FIXED, not for
FLOAT.; in particular, whether it supported FIXED BIN(127,0).
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
You would not need vector instructions to support FIXED BIN(127,s)
(quad-word scaled
or unscaled integers if s is 0.)
In fact, you could do it with 370 code (our C compiler happens to do
that for __int128
and __uint128.)
The problems come when consider conversions to-from other items... the
definitions
of those conversions are pretty straight-forward. The issue is
examining all the conversion
permutations for PL/I to make sure it's implemented... then there are
the library I/O
characteristics to consider (which are mostly handled by the conversion
answers.)
Will you need a PIC that handles this, is the maximum PIC length
sufficent (_lots_
of base-10 digits in those things.) Do you need to read the values
from a FILE,
then you'll need CHAR -> FIXED BIN(127,s) conversion support... etc...
Our C compiler, as well as GCC, gets around this by saying you can
declare 128-bit
integers, and do basic arithmetic with them - but the runtime library
doesn't support them
(so formating for printing, for example, is up-to-you.) That seems to
handle the current
uses for 128-bit integral arithmetic. Of course, C doesn't have scaled
integers, making
the problem even easier there.
And - to drive the point home - let's consider this small snippet:
__int128
foo(__int128 a, __int128 b)
{
return a + b;
}
which just adds 2 128-bit signed integers. This is the 370 code that
is generated
from our C compiler:
* *** End of Prologue
* *
L 15,0(0,1)
* *** return a + b;
LM2,5,4(1)
AL5,32(0,1)
BC 12,@@gen_label0
AL4,@lit_147_0
BC 12,@@gen_label0
AL3,@lit_147_0
BC 12,@@gen_label0
AL2,@lit_147_0
@@gen_label0 DS 0H
AL4,28(0,1)
BC 12,@@gen_label1
AL3,@lit_147_0
BC 12,@@gen_label1
AL2,@lit_147_0
@@gen_label1 DS 0H
AL3,24(0,1)
BC 12,@@gen_label2
AL2,@lit_147_0
@@gen_label2 DS 0H
AL2,20(0,1)
STM 2,5,95(13)
MVC 0(16,15),95(13)
* *** }
* * Start of Epilogue
which is quite a lot!
But - if you tell the compiler it can take advantage of more recent
architectures (with
the -march=z13 option) - that same snippet generates this (in 31-bit mode):
* *** End of Prologue
* *
L 15,0(0,1)
* *** return a + b;
LMG 2,3,4(1)
ALG 3,28(0,1)
ALCG 2,20(0,1)
STMG 2,3,95(13)
MVC 0(16,15),95(13)
* *** }
* * Start of Epilogue
which is a better demonstration of how to do 128-bit arithmetic without
vector
instructions.
- Dave R. -
p.s. the return value is address via the first incoming parameter
(0(0,1)) if that helps
make sense of what's going on here.
p.p.s. This facility would be available in LE mode too, so you _could_
compile
C code with our compiler and link it with the IBM PL/I
compiler to do your
128-bit arithmetic; with careful definitions of the C
functions an PL/I EXTRNs.
But, it might just be easier to write the PL/I PROCs to do
the various arithmetic
functions on 128-bit values held in structures - or maybe
get really fancy
and use the PL/I preprocessor to generate the code for the
basic operations.
--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
OS/360 always runs in BC mode. MVS 3.8J and earlier IPL in BC mode and then change the PSW to EC mode. Joe On Wed, Sep 9, 2020 at 4:47 PM Seymour J Metz wrote: > In XA mode the problem is the SIO instruction. DOS.360, OS/360, OS/VS, > etc. don't support SSCH. Does OS/360 need BC when you sysgen for S/370? I'm > certain;ly not aware of such a dependency in OS/VS or VM. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Lennie Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> > Sent: Wednesday, September 9, 2020 4:56 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Architectural Level Sets > > I think this happened with the move to MVS/XA as XA does not recognise a > BC mode PSW. > So I guess it was the first machine which did not support architectures > earlier than MVS/XA. > I suspect that was the 3081. > > All my conjecture of course. Let's see what the IBM oracles tell us. > > Lennie Dymoke-Bradshaw > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Mark S Waterbury > Sent: 09 September 2020 18:35 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Architectural Level Sets > > To add to this thread ... > > I would like to know at what point during the evolution from S/370 to > S/370-XA to S/390 to zSeries, did the architecture stop supporting IPL of > any OS that runs in "BC mode" or that starts out in BC mode, before setting > up page and segment tables and control registers and then enabling DAT? > > In other words, what processor family(s) and specific models in that > family, if need be, can no longer IPL and run any of the "public domain" > operating systems from the 1970s to early 1980s? (DOS/360, OS/360, DOS/VS, > OS/VS1, OS/VS2, VM/370, TSS/370, etc.) > > Thanks in advance. > > Mark S. Waterbury > > -- > 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: EXTERNAL: Re: PL/I support of vector instructions?
There is an LE run time option that controls whether messages are produced for errors, or not ... your installation option has chosen no message. You can set runtime options at system, job or individual program level. Your cobol program can even call CEEHDLR to set its own condition handler. None of this is related to compiler options, it is Language Environment. Having a potential storage overlay turned into correct result automagically is pretty impressive, imho, but I agree that changing compiler options for optimization can often expose latent programming bugs. Hopefully that program isn't still running unmodified in 2100 when the leap year calculation will be wrong :) On Thu, Sep 10, 2020 at 8:32 AM Savor, Thomas < 0330b7631be3-dmarc-requ...@listserv.ua.edu> wrote: > >Enterprise PL/I 5.2 supports ARCH(12) so has your desired vector > instruction support. For completeness, so do Cobol 6.2, XL/C 2.3 and Java > 8.5. >Again no source code change in PL/I is needed, just recompile with > >ARCH(12) option. Really sad that IBM doesn't publicize these features > better vector usage can cut cpu and elapsed time dramatically (I've > >seen 80% reduction for intensive programs). Great reason to upgrade the > hardware and compilers :) > > The vector instructions are faster ...we saw about 15% between ARCH(11) to > ARCH(12). > BUT. > Before we got to that point, we have the rug yanked out from under us as > evidently these vector instructions are VERY sensitive to field sizes. > Example: The application that I was supporting, some of this code is from > VSE (late 70's), on every transaction, the transaction date is calculated > to insure if Leap Year or not. This calculation has been there for 30+ > years, it could care less what the answer is, just the remainder. If > remainder, not a leap year in simple termsanyway answer field was to > small to do calculation...previous versions of Cobol or ARCH levels > truncated the answer and we moved on and were happy. ARCH(12), caused a > major job that processed 1.5 million transactions to go from 10-15 minutes > to 1.5 to 2 hours. Why ?? Jobs ran to successful completion, but every > transaction abended, went into abend recovery, recovered...said > nothing...and continued onward. Strobe said that we were spending 95% of > our time in abend recovery...which upon further investigation pointed to > Leap Year calculation error. My opinion, Cobol should tell you when going > into abend recovery, but it didn’t. > > Thanks, > > Tom > > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > > -- > 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: Architectural Level Sets
Hi Clark, Did you run MVS on a 4341? If yes, which version? Thanks and regards, David On 2020-09-09 19:12, Clark Morris wrote: [Default] On 9 Sep 2020 14:47:15 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: In XA mode the problem is the SIO instruction. DOS.360, OS/360, OS/VS, etc. don't support SSCH. Does OS/360 need BC when you sysgen for S/370? I'm certain;ly not aware of such a dependency in OS/VS or VM. MVT ran on a 4341 generated as a 370/158 in my shop while we were upgrading to MVS. Clark Morris -- 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: Architectural Level Sets
[Default] On 9 Sep 2020 14:47:15 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >In XA mode the problem is the SIO instruction. DOS.360, OS/360, OS/VS, etc. >don't support SSCH. Does OS/360 need BC when you sysgen for S/370? I'm >certain;ly not aware of such a dependency in OS/VS or VM. MVT ran on a 4341 generated as a 370/158 in my shop while we were upgrading to MVS. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL: Re: PL/I support of vector instructions?
>Enterprise PL/I 5.2 supports ARCH(12) so has your desired vector instruction >support. For completeness, so do Cobol 6.2, XL/C 2.3 and Java 8.5. >Again no >source code change in PL/I is needed, just recompile with >ARCH(12) option. Really sad that IBM doesn't publicize these features >better vector usage can cut cpu and elapsed time dramatically (I've >seen >80% reduction for intensive programs). Great reason to upgrade the hardware >and compilers :) The vector instructions are faster ...we saw about 15% between ARCH(11) to ARCH(12). BUT. Before we got to that point, we have the rug yanked out from under us as evidently these vector instructions are VERY sensitive to field sizes. Example: The application that I was supporting, some of this code is from VSE (late 70's), on every transaction, the transaction date is calculated to insure if Leap Year or not. This calculation has been there for 30+ years, it could care less what the answer is, just the remainder. If remainder, not a leap year in simple termsanyway answer field was to small to do calculation...previous versions of Cobol or ARCH levels truncated the answer and we moved on and were happy. ARCH(12), caused a major job that processed 1.5 million transactions to go from 10-15 minutes to 1.5 to 2 hours. Why ?? Jobs ran to successful completion, but every transaction abended, went into abend recovery, recovered...said nothing...and continued onward. Strobe said that we were spending 95% of our time in abend recovery...which upon further investigation pointed to Leap Year calculation error. My opinion, Cobol should tell you when going into abend recovery, but it didn’t. Thanks, Tom The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I support of vector instructions?
z13 added many SIMD (vector) instructions for both binary arithmetic and strings and most support from 8b to 128b wide operands. The compilers were updated to use SIMD for some functions, including binary integer and string; this was for PLI 4.5. You need PLI 5.3 (newest compiler) for ARCH(13) support. I've never investigated how extensive the SIMD exploitation was as retrofitted into PLI 4.5. I believe PLI 5.3 supports FIXED BIN(127,0) within the limits of the hardware -- for example there is 128 bit vector add/subtract with carry, and also 128b to 8b arithmetic, but not some of the other variants. This varies between z13, z14 and z15. On Thu, Sep 10, 2020 at 7:54 AM Seymour J Metz wrote: > I was asking whether it supported vector instructions for FIXED, not for > FLOAT.; in particular, whether it supported FIXED BIN(127,0). > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Attila Fogarasi > Sent: Wednesday, September 9, 2020 5:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PL/I support of vector instructions? > > There is no source change as the DFP option applies only to DEC FLOAT and > not to FIXED BIN. The data element storage sizes remain the same, but with > DFP the DEC FLOAT items become decimal floating point data and instructions > (and BIF) while with NODFP the DEC FLOAT is HEXADECIMAL float (as distinct > from the older BINARY float, which is not IEE754 compliant). Confusing > having 3 incompatible and numerically incongruent floating point formats on > the same machine, and only DFP should be used now as it is both faster. (on > all supported z hardware today), more accurate, and more storage dense. To > IBM's credit they have the best IEE754 implementation and went with the > expensive hardware option. > As for the vector facility, currently there are 32 vector registers, 128 > bit wide. The z14 extensions added DFP to vector and also quad-precision > capability. You do need to set multiple compiler options correctly to get > vector code generated :) > > On Thu, Sep 10, 2020 at 12:22 AM Seymour J Metz wrote: > > > No source change? Certainly the compiler could interpret FIXED BIN as > > FIXED BIN(127,0), but if I've coded, e.g., FIXED BIN(60,3), I would hope > > that the compiler would only use a doubleword unless and until I changed > > the source and recompiled. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > > > From: IBM Mainframe Discussion List on behalf > > of Attila Fogarasi > > Sent: Wednesday, September 9, 2020 2:14 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: PL/I support of vector instructions? > > > > Enterprise PL/I 5.2 supports ARCH(12) so has your desired vector > > instruction support. For completeness, so do Cobol 6.2, XL/C 2.3 and > Java > > 8.5. Again no source code change in PL/I is needed, just recompile with > > ARCH(12) option. Really sad that IBM doesn't publicize these features > > better vector usage can cut cpu and elapsed time dramatically (I've > > seen 80% reduction for intensive programs). Great reason to upgrade the > > hardware and compilers :) > > > > On Wed, Sep 9, 2020 at 3:59 PM Attila Fogarasi > wrote: > > > > > For greater precision Enterprise PLI supports the hardware Decimal > > > Floating Point which is enabled with the compiler option of FLOAT(DFP), > > > this then changes all the DECIMAL FLOAT data declarations to be DFP > > > allowing maximum 34 digits (and exact decimal precision, important for > > > financial applications). The PL/I language itself is unchanged, so > > > existing source code switches to using DFP with a recompile (though > > changes > > > in DCL might be desirable). Vector DFP is part of ARCH(12) which came > > with > > > z14. So Enterprise PLI fully supports it already, best I can tell, but > > > doesn't highlight such support in the doc. I do DFP in assembler as I > > > couldn't wait for the compilers to add support and also want finer > > control > > > (the devil is in the details). > > > > > > On Wed, Sep 9, 2020 at 2:53 PM Seymour J Metz wrote: > > > > > >> Has IBM announced an intention to support the vector instructions to > > >> allow more precision for FIXED DEC and FIXED BIN in PL/I? Are there > > other > > >> vendors that support greater precision? > > >> > > >> > > >> -- > > >> 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
Re: Syncsort include/omit beyond record
On Wed, 9 Sep 2020 14:31:24 -0700, Sri h Kolusu wrote: > >>>Are complicated Boolean expressions supported? > >Yes. Check this link > >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.icea100/ice2ca_Relational_condition.htm > Thanks. I see: AND statements are evaluated before OR statements unless parentheses are used to change the order of evaluation; expressions inside parentheses are always evaluated first. (Nesting of parentheses is limited only by the amount of storage available.) It would be useful to see an example where "parentheses are used to change the order of evaluation." Perhaps: INCLUDE=((5,4,BI,LT,11,4,BI),AND,((21,4,BI,EQ,31,4,BI),OR, (61,20,SS,EQ,C'FLY'))) Are the commas in the right places? (I added some needless parentheses just for practice.) Is there a NOT or must the programmer use De Morgan's Laws? Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I support of vector instructions?
I was asking whether it supported vector instructions for FIXED, not for FLOAT.; in particular, whether it supported FIXED BIN(127,0). -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Attila Fogarasi Sent: Wednesday, September 9, 2020 5:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I support of vector instructions? There is no source change as the DFP option applies only to DEC FLOAT and not to FIXED BIN. The data element storage sizes remain the same, but with DFP the DEC FLOAT items become decimal floating point data and instructions (and BIF) while with NODFP the DEC FLOAT is HEXADECIMAL float (as distinct from the older BINARY float, which is not IEE754 compliant). Confusing having 3 incompatible and numerically incongruent floating point formats on the same machine, and only DFP should be used now as it is both faster. (on all supported z hardware today), more accurate, and more storage dense. To IBM's credit they have the best IEE754 implementation and went with the expensive hardware option. As for the vector facility, currently there are 32 vector registers, 128 bit wide. The z14 extensions added DFP to vector and also quad-precision capability. You do need to set multiple compiler options correctly to get vector code generated :) On Thu, Sep 10, 2020 at 12:22 AM Seymour J Metz wrote: > No source change? Certainly the compiler could interpret FIXED BIN as > FIXED BIN(127,0), but if I've coded, e.g., FIXED BIN(60,3), I would hope > that the compiler would only use a doubleword unless and until I changed > the source and recompiled. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Attila Fogarasi > Sent: Wednesday, September 9, 2020 2:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PL/I support of vector instructions? > > Enterprise PL/I 5.2 supports ARCH(12) so has your desired vector > instruction support. For completeness, so do Cobol 6.2, XL/C 2.3 and Java > 8.5. Again no source code change in PL/I is needed, just recompile with > ARCH(12) option. Really sad that IBM doesn't publicize these features > better vector usage can cut cpu and elapsed time dramatically (I've > seen 80% reduction for intensive programs). Great reason to upgrade the > hardware and compilers :) > > On Wed, Sep 9, 2020 at 3:59 PM Attila Fogarasi wrote: > > > For greater precision Enterprise PLI supports the hardware Decimal > > Floating Point which is enabled with the compiler option of FLOAT(DFP), > > this then changes all the DECIMAL FLOAT data declarations to be DFP > > allowing maximum 34 digits (and exact decimal precision, important for > > financial applications). The PL/I language itself is unchanged, so > > existing source code switches to using DFP with a recompile (though > changes > > in DCL might be desirable). Vector DFP is part of ARCH(12) which came > with > > z14. So Enterprise PLI fully supports it already, best I can tell, but > > doesn't highlight such support in the doc. I do DFP in assembler as I > > couldn't wait for the compilers to add support and also want finer > control > > (the devil is in the details). > > > > On Wed, Sep 9, 2020 at 2:53 PM Seymour J Metz wrote: > > > >> Has IBM announced an intention to support the vector instructions to > >> allow more precision for FIXED DEC and FIXED BIN in PL/I? Are there > other > >> vendors that support greater precision? > >> > >> > >> -- > >> 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 > > -- > 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: Architectural Level Sets
In XA mode the problem is the SIO instruction. DOS.360, OS/360, OS/VS, etc. don't support SSCH. Does OS/360 need BC when you sysgen for S/370? I'm certain;ly not aware of such a dependency in OS/VS or VM. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lennie Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, September 9, 2020 4:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural Level Sets I think this happened with the move to MVS/XA as XA does not recognise a BC mode PSW. So I guess it was the first machine which did not support architectures earlier than MVS/XA. I suspect that was the 3081. All my conjecture of course. Let's see what the IBM oracles tell us. Lennie Dymoke-Bradshaw -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark S Waterbury Sent: 09 September 2020 18:35 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural Level Sets To add to this thread ... I would like to know at what point during the evolution from S/370 to S/370-XA to S/390 to zSeries, did the architecture stop supporting IPL of any OS that runs in "BC mode" or that starts out in BC mode, before setting up page and segment tables and control registers and then enabling DAT? In other words, what processor family(s) and specific models in that family, if need be, can no longer IPL and run any of the "public domain" operating systems from the 1970s to early 1980s? (DOS/360, OS/360, DOS/VS, OS/VS1, OS/VS2, VM/370, TSS/370, etc.) Thanks in advance. Mark S. Waterbury -- 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: PL/I support of vector instructions?
There is no source change as the DFP option applies only to DEC FLOAT and not to FIXED BIN. The data element storage sizes remain the same, but with DFP the DEC FLOAT items become decimal floating point data and instructions (and BIF) while with NODFP the DEC FLOAT is HEXADECIMAL float (as distinct from the older BINARY float, which is not IEE754 compliant). Confusing having 3 incompatible and numerically incongruent floating point formats on the same machine, and only DFP should be used now as it is both faster. (on all supported z hardware today), more accurate, and more storage dense. To IBM's credit they have the best IEE754 implementation and went with the expensive hardware option. As for the vector facility, currently there are 32 vector registers, 128 bit wide. The z14 extensions added DFP to vector and also quad-precision capability. You do need to set multiple compiler options correctly to get vector code generated :) On Thu, Sep 10, 2020 at 12:22 AM Seymour J Metz wrote: > No source change? Certainly the compiler could interpret FIXED BIN as > FIXED BIN(127,0), but if I've coded, e.g., FIXED BIN(60,3), I would hope > that the compiler would only use a doubleword unless and until I changed > the source and recompiled. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Attila Fogarasi > Sent: Wednesday, September 9, 2020 2:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PL/I support of vector instructions? > > Enterprise PL/I 5.2 supports ARCH(12) so has your desired vector > instruction support. For completeness, so do Cobol 6.2, XL/C 2.3 and Java > 8.5. Again no source code change in PL/I is needed, just recompile with > ARCH(12) option. Really sad that IBM doesn't publicize these features > better vector usage can cut cpu and elapsed time dramatically (I've > seen 80% reduction for intensive programs). Great reason to upgrade the > hardware and compilers :) > > On Wed, Sep 9, 2020 at 3:59 PM Attila Fogarasi wrote: > > > For greater precision Enterprise PLI supports the hardware Decimal > > Floating Point which is enabled with the compiler option of FLOAT(DFP), > > this then changes all the DECIMAL FLOAT data declarations to be DFP > > allowing maximum 34 digits (and exact decimal precision, important for > > financial applications). The PL/I language itself is unchanged, so > > existing source code switches to using DFP with a recompile (though > changes > > in DCL might be desirable). Vector DFP is part of ARCH(12) which came > with > > z14. So Enterprise PLI fully supports it already, best I can tell, but > > doesn't highlight such support in the doc. I do DFP in assembler as I > > couldn't wait for the compilers to add support and also want finer > control > > (the devil is in the details). > > > > On Wed, Sep 9, 2020 at 2:53 PM Seymour J Metz wrote: > > > >> Has IBM announced an intention to support the vector instructions to > >> allow more precision for FIXED DEC and FIXED BIN in PL/I? Are there > other > >> vendors that support greater precision? > >> > >> > >> -- > >> 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 > > -- > 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: Syncsort include/omit beyond record
>>>Suppose the programmer wishes to compare to binary zeroes, Gil, Comparing to binary zeros will let you include short records who have length less than 21 bytes. But that is an easy fix. Since we are dealing with VB records, the actual length is in RDW so you can add the RDW validation in the INCLUDE condition. Something like this //SYSINDD * OPTION COPY,VLSCMP INCLUDE COND=(01,2,BI,GE,21,AND, 21,1,CH,EQ,X'00') /* >>Are complicated Boolean expressions supported? Yes. Check this link https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.icea100/ice2ca_Relational_condition.htm Thanks, Kolusu DFSORT Development IBM Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
According to this guide, the 3090 could still start in BC mode when in 370 mode. See page 7-6. http://vtda.org/docs/computing/IBM/Mainframe/Hardware/System/SA22-7121-6_3090ProcComplexFunctionalCharacteristics.pdf Joe On Wed, Sep 9, 2020, 16:07 Lennie Bradshaw < 032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote: > I think this happened with the move to MVS/XA as XA does not recognise a > BC mode PSW. > So I guess it was the first machine which did not support architectures > earlier than MVS/XA. > I suspect that was the 3081. > > All my conjecture of course. Let's see what the IBM oracles tell us. > > Lennie Dymoke-Bradshaw > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Mark S Waterbury > Sent: 09 September 2020 18:35 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Architectural Level Sets > > To add to this thread ... > > I would like to know at what point during the evolution from S/370 to > S/370-XA to S/390 to zSeries, did the architecture stop supporting IPL of > any OS that runs in "BC mode" or that starts out in BC mode, before setting > up page and segment tables and control registers and then enabling DAT? > > In other words, what processor family(s) and specific models in that > family, if need be, can no longer IPL and run any of the "public domain" > operating systems from the 1970s to early 1980s? (DOS/360, OS/360, DOS/VS, > OS/VS1, OS/VS2, VM/370, TSS/370, etc.) > > Thanks in advance. > > Mark S. Waterbury > > -- > 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: Syncsort include/omit beyond record
On Wed, 9 Sep 2020 13:15:43 -0700, Sri h Kolusu wrote: > >VLSCMP tells DFSORT that you want to temporarily replace any missing >compare field bytes with binary zeros, thus allowing the short fields to be >validly compared (the binary zeros are not kept for the output records). > >So use the following control cards > >OPTION COPY,VLSCMP >OMIT COND=(21,8,CH,NE,C'TYPE 200') > >So any records that do NOT contain the string "TYPE 200" will be OMITTED. > Suppose the programmer wishes to compare to binary zeroes, as INCLUDE COND=(21,1,CH,EQ,X'00') ... but only if the record is at least 21 characters long and has an actual X'00' in column 21? Do AND and OR help? Are complicated Boolean expressions supported? I'm imagining something I might code in Rexx such as: surname='Roosevelt' & ( forename='Theodore' | forename='Franklin' ) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
I think this happened with the move to MVS/XA as XA does not recognise a BC mode PSW. So I guess it was the first machine which did not support architectures earlier than MVS/XA. I suspect that was the 3081. All my conjecture of course. Let's see what the IBM oracles tell us. Lennie Dymoke-Bradshaw -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark S Waterbury Sent: 09 September 2020 18:35 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural Level Sets To add to this thread ... I would like to know at what point during the evolution from S/370 to S/370-XA to S/390 to zSeries, did the architecture stop supporting IPL of any OS that runs in "BC mode" or that starts out in BC mode, before setting up page and segment tables and control registers and then enabling DAT? In other words, what processor family(s) and specific models in that family, if need be, can no longer IPL and run any of the "public domain" operating systems from the 1970s to early 1980s? (DOS/360, OS/360, DOS/VS, OS/VS1, OS/VS2, VM/370, TSS/370, etc.) Thanks in advance. Mark S. Waterbury -- 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: Syncsort include/omit beyond record
> A Google search seems to find those as SYNCSORT options but not as > DFSORT options. Is that right? But on: Gil, Both products have different parms. >>> What other comparison operators are available. For example, I'd > be interested in whether: OMIT COND=(21,8,CH,NE,C'Type 200') You need to use VLSCMP instead of VLSHRT VLSCMP tells DFSORT that you want to temporarily replace any missing compare field bytes with binary zeros, thus allowing the short fields to be validly compared (the binary zeros are not kept for the output records). So use the following control cards OPTION COPY,VLSCMP OMIT COND=(21,8,CH,NE,C'TYPE 200') So any records that do NOT contain the string "TYPE 200" will be OMITTED. Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
There are two different issues. The free S/360 and S/370 operating systems require S/370 mode, as do the proprietary systems prior to XA and ESA. They use SIO, which does not exist in XA, ESA or z mode. Support for that disappeared earlier than support for XA and ESA. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mark S Waterbury <01c3f560aac1-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, September 9, 2020 1:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural Level Sets To add to this thread ... I would like to know at what point during the evolution from S/370 to S/370-XA to S/390 to zSeries, did the architecture stop supporting IPL of any OS that runs in "BC mode" or that starts out in BC mode, before setting up page and segment tables and control registers and then enabling DAT? In other words, what processor family(s) and specific models in that family, if need be, can no longer IPL and run any of the "public domain" operating systems from the 1970s to early 1980s? (DOS/360, OS/360, DOS/VS, OS/VS1, OS/VS2, VM/370, TSS/370, etc.) Thanks in advance. Mark S. Waterbury -- 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: Syncsort include/omit beyond record
DFSORT and SYNCSORT options are just not the same for this feature. The wording would seem to imply that *any* comparison will be treated as false. The SYNCSORT description for VLTESTI=2 seems to imply the same behavior (note the last sentence in this quote): "When VLTESTI=2 is specified, MFX will treat comparisons to fields not completely contained within the record as false and decide a record’s status for inclusion or omission from fields that are available. If all fields are not present, the record will be processed as having failed the comparison. MFX will omit the record if INCLUDE is being used or include the record if OMIT has been specified." There is a full suite of field comparison operators in both SORT programs. EQ, NE, LT, LE, GT, GE, and some specialty operators like SS for substring compare. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Wednesday, September 9, 2020 2:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Syncsort include/omit beyond record On Wed, 9 Sep 2020 17:19:55 +, Farley, Peter x23353 wrote: >Use these PARM options for SYNCSORT to allow field references beyond the >actual input record length: > >PARM=VLLTEST=2,VLTESTI=2' > >One of your VB input records is less than 17 bytes long (21 - 4 = 17). > A Google search seems to find those as SYNCSORT options but not as DFSORT options. Is that right? But on: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.iceg200/ice2cg_Short_control_fields1.htm Another way you can prevent DFSORT from terminating for VB records with short compare fields, if appropriate, is by specifying the VLSHRT option. For example: OPTION COPY,VLSHRT INCLUDE COND=(21,8,CH,EQ,C'Type 200') VLSHRT tells DFSORT to treat any comparison involving a short field as false. In this example, any records less than 28 bytes are not included. What other comparison operators are available. For example, I'd be interested in whether: OMIT COND=(21,8,CH,NE,C'Type 200') ... causes short records *not* to be omitted because "NE" is false. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
z13 will IPL a 24 bit O/S. z14 will not support a 24 bit DAT. ZZSA and non-virtual memory utilities should still run. On Wed, Sep 9, 2020 at 12:35 PM Mark S Waterbury <01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote: > > To add to this thread ... > > I would like to know at what point during the evolution from S/370 to > S/370-XA to S/390 to zSeries, did the architecture stop supporting IPL of any > OS that runs in "BC mode" or that starts out in BC mode, before setting up > page and segment tables and control registers and then enabling DAT? > > In other words, what processor family(s) and specific models in that family, > if need be, can no longer IPL and run any of the "public domain" operating > systems from the 1970s to early 1980s? (DOS/360, OS/360, DOS/VS, OS/VS1, > OS/VS2, VM/370, TSS/370, etc.) > > Thanks in advance. > > Mark S. Waterbury > > -- > 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: Syncsort include/omit beyond record
On Wed, 9 Sep 2020 17:19:55 +, Farley, Peter x23353 wrote: >Use these PARM options for SYNCSORT to allow field references beyond the >actual input record length: > >PARM=VLLTEST=2,VLTESTI=2' > >One of your VB input records is less than 17 bytes long (21 - 4 = 17). > A Google search seems to find those as SYNCSORT options but not as DFSORT options. Is that right? But on: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.iceg200/ice2cg_Short_control_fields1.htm Another way you can prevent DFSORT from terminating for VB records with short compare fields, if appropriate, is by specifying the VLSHRT option. For example: OPTION COPY,VLSHRT INCLUDE COND=(21,8,CH,EQ,C'Type 200') VLSHRT tells DFSORT to treat any comparison involving a short field as false. In this example, any records less than 28 bytes are not included. What other comparison operators are available. For example, I'd be interested in whether: OMIT COND=(21,8,CH,NE,C'Type 200') ... causes short records *not* to be omitted because "NE" is false. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
To add to this thread ... I would like to know at what point during the evolution from S/370 to S/370-XA to S/390 to zSeries, did the architecture stop supporting IPL of any OS that runs in "BC mode" or that starts out in BC mode, before setting up page and segment tables and control registers and then enabling DAT? In other words, what processor family(s) and specific models in that family, if need be, can no longer IPL and run any of the "public domain" operating systems from the 1970s to early 1980s? (DOS/360, OS/360, DOS/VS, OS/VS1, OS/VS2, VM/370, TSS/370, etc.) Thanks in advance. Mark S. Waterbury -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Syncsort include/omit beyond record
Thanks > On Sep 9, 2020, at 1:20 PM, Farley, Peter x23353 > <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > > Use these PARM options for SYNCSORT to allow field references beyond the > actual input record length: > > PARM='VLTEST=2,VLTESTI=2' > > One of your VB input records is less than 17 bytes long (21 - 4 = 17). > > HTH > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Joseph Reichman > Sent: Wednesday, September 9, 2020 11:59 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Syncsort include/omit beyond record > > EXTERNAL EMAIL > > Hi > I am getting the above message on sortin being a VB record lrecl 3196 > blocksize 32000 > > The include is > Include cond=(21,1,BI,EQ,X’01’) > > Looking for x’01’ in pos 21 ( including RDW) > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. If > the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system. > > > -- > 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: Syncsort include/omit beyond record
Use these PARM options for SYNCSORT to allow field references beyond the actual input record length: PARM='VLTEST=2,VLTESTI=2' One of your VB input records is less than 17 bytes long (21 - 4 = 17). HTH Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Wednesday, September 9, 2020 11:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Syncsort include/omit beyond record EXTERNAL EMAIL Hi I am getting the above message on sortin being a VB record lrecl 3196 blocksize 32000 The include is Include cond=(21,1,BI,EQ,X’01’) Looking for x’01’ in pos 21 ( including RDW) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Syncsort include/omit beyond record
Hi I am getting the above message on sortin being a VB record lrecl 3196 blocksize 32000 The include is Include cond=(21,1,BI,EQ,X’01’) Looking for x’01’ in pos 21 ( including RDW) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX true/false (was Constant Identifiers)
On Wed, 9 Sep 2020 00:45:12 -0400, Phil Smith III wrote: >Y'all are dancing on the head of a pin. As Shmuel said, Rexx has one datatype, >period. It has the DATATYPE function that can do some >analysis on a variable's contents and tell you whether it's all numeric, hex, >etc. That's basically it. Arguing about whether it's a >"string" or a "character string" is just more dancing: since there's only the >one type, what does it matter? > In creative writing, variety is the soul; in technical writing, it's the devil. Using "string" in some places and "character string" in others without defining both is bad practice. This fiber of the thread frayed off when someone with a PL/I background said that in Rexx '1'b can be used as [a value for TRUE]. No, it's syntactically invalid to do that. On Wed, 9 Sep 2020 04:49:13 +, Seymour J Metz wrote: >Have you ever heard of PL/I? Much of the syntax of REXX derives from PL/I, and >it has two different string types: CHARACTER and BIT. > But it is not the responsibility of Rexx documentation to distinguish itself and/or adopt jargon from that of all other programming languages. In TSO-Rexx James Campbell posted a good critique of my critique. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I Integer arithmetic
You did, in the comment. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Wednesday, September 9, 2020 11:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I Integer arithmetic On 2020-09-10 00:33, Seymour J Metz wrote: > Since when is 1.33... an integer? Who said it was? A/B (both integers with values 4 and 3 respectively), yield exactly 1. > > From: IBM Mainframe Discussion List on > behalf of Robin Vowels > Sent: Wednesday, September 9, 2020 10:08 AM > Subject: Re: PL/I Integer arithmetic (was: Constant Identifiers) > > From: "Seymour J Metz" > Sent: Monday, September 07, 2020 4:13 PM > > >> PL/I has never had integers. > > It always has had integers. > >> The arithmetic rules for scaled fixed point are different from those >> for integers. >> In integer arithmetic, (4/3)*6 is 6 That's not the result you get in >> PL/I. > > Yes it is, with declarations as shown, as I said before, . > > Under IBM rules: > > %PROCESS RULES(IBM); > INTEGER_DIVISION: >PROCEDURE OPTIONS (MAIN); >DECLARE (A, B) FIXED DECIMAL (15); > >A = 4; B = 3; > >PUT (4/3); >PUT (A/B); >PUT ( (A/B) * 6 ); > > END INTEGER_DIVISION; > /* RESULTS: > 1.33 1 6 > */ -- 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: PL/I Integer arithmetic
On 2020-09-10 00:33, Seymour J Metz wrote: Since when is 1.33... an integer? Who said it was? A/B (both integers with values 4 and 3 respectively), yield exactly 1. From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Wednesday, September 9, 2020 10:08 AM Subject: Re: PL/I Integer arithmetic (was: Constant Identifiers) From: "Seymour J Metz" Sent: Monday, September 07, 2020 4:13 PM PL/I has never had integers. It always has had integers. The arithmetic rules for scaled fixed point are different from those for integers. In integer arithmetic, (4/3)*6 is 6 That's not the result you get in PL/I. Yes it is, with declarations as shown, as I said before, . Under IBM rules: %PROCESS RULES(IBM); INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I Integer arithmetic.
On 2020-09-10 00:32, Seymour J Metz wrote: The results that you have described are not integer arithmetic. In integer arithmetic, 4/3 is 1. Look at the second result following the program. You will see that A/B == 4/3 yields 1. From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Wednesday, September 9, 2020 10:14 AM - Original Message - From: "Seymour J Metz" Sent: Monday, September 07, 2020 3:02 PM Subject: Re: Constant Identifiers 4/3 yields 1.3, 04/3 yields 1332, ... Rubbish. 4/3 yields 1.33 INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ However, DIVIDE(4,3,16,15) yields 1.3...2 to 15 digits No, it yields 1.33 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I Integer arithmetic (was: Constant Identifiers)
Since when is 1.33... an integer? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Wednesday, September 9, 2020 10:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I Integer arithmetic (was: Constant Identifiers) From: "Seymour J Metz" Sent: Monday, September 07, 2020 4:13 PM > PL/I has never had integers. It always has had integers. > The arithmetic rules for scaled fixed point are different from those for > integers. > In integer arithmetic, (4/3)*6 is 6 That's not the result you get in PL/I. Yes it is, with declarations as shown, as I said before, . Under IBM rules: %PROCESS RULES(IBM); INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ And under Rules (ans): %PROCESS RULES(ANS); INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ As you can see, the results are the same under IBM and ANS rules. From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Sunday, September 6, 2020 7:06 PM Subject: Re: Constant Identifiers - Original Message - From: "Seymour J Metz" Sent: Monday, September 07, 2020 5:33 AM > PL/I doesn't have integers. PL/I has always had integers. > The ratiio 4/3 is FIXED BIN, No it not. It is FIXED DECIMAL -- as I said a few days ago. And it hasn't changed since. > with some number of bits after the binary point. DECIMAL digits after the decimal point, because the reault is FIXED DECIMAL, not binary. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- 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: PL/I expressions (was Constant Identifiers)
From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Sunday, September 06, 2020 1:33 PM On Sat, 5 Sep 2020 08:13:42 +1000, Robin Vowels wrote: As for writing formulas, I prefer to follow a well-known formula, thus: volume = 4/3 * 3.14159 * radius**3 Beware! Than might left-associate as: volume = ( 4/3 ) * 3.14159 * radius**3 Under the left-to-right rule, that's precisely how the original exression would be interpreted. The paretheses are redundany. ... and the quotient of integers, 4/3, is 1. No it isn't. 4/3 yields 1.33 However, if I'm interested in efficiency, I'd prefer volume = 4 * 3.14159E0 / 3 * radius**3 ... (and correct.) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I Integer arithmetic. (was: Constant Identifiers)
The results that you have described are not integer arithmetic. In integer arithmetic, 4/3 is 1. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Wednesday, September 9, 2020 10:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I Integer arithmetic. (was: Constant Identifiers) - Original Message - From: "Seymour J Metz" Sent: Monday, September 07, 2020 3:02 PM Subject: Re: Constant Identifiers 4/3 yields 1.3, 04/3 yields 1332, ... Rubbish. 4/3 yields 1.33 INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ However, DIVIDE(4,3,16,15) yields 1.3...2 to 15 digits No, it yields 1.33 From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Sunday, September 6, 2020 7:58 PM Subject: Re: Constant Identifiers From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Sunday, September 06, 2020 1:33 PM On Sat, 5 Sep 2020 08:13:42 +1000, Robin Vowels wrote: > >As for writing formulas, I prefer to follow a well-known formula, thus: > >volume = 4/3 * 3.14159 * radius**3 > Beware! Than might left-associate as: volume = ( 4/3 ) * 3.14159 * radius**3 "might"? Evaluation MUST proceed left to right. So, whether it is written as 4/3 or (4/3), the division will be done first. > ... and the quotient of integers, 4/3, is 1. As I indicaed before, 4/3 yields 1.333.to 15 digits. >However, if I'm interested in efficiency, I'd prefer > >volume = 4 * 3.14159E0 / 3 * radius**3 > ... (and correct.) Yes, it's correct, but I wrote it that way in order to avoid unnecessary conversions and arithmetic in fixed-point. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- 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: PL/I Division (was Constant Identifiers)
If the results are as you claim then it isn't integer division. Make up your mind. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Wednesday, September 9, 2020 10:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I Division (was Constant Identifiers) From: "Joe Monk" Sent: Monday, September 07, 2020 1:05 PM > "No it isn't. 4/3 yields 1.33... to 15 digits, > and is of precision (15,14)" > > Depends on RULES(IBM) or RULES(ANS). If its RULES(IBM) it will never be > integer division. If its RULES(ANS) and the operands are unscaled, then it > will be integer division. No it doesn't. See results appended to program. INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ > On Sun, Sep 6, 2020 at 7:34 PM Robin Vowels wrote: > >> On 2020-09-07 09:35, Joe Monk wrote: >> > "PL/I doesn't have integers." >> > >> > Sorry Shmuel, youre incorrect. >> > >> > FIXED BINARY (15,0) is a 2 byte integer and FIXED BINARY (31,0) is a 4 >> > byte >> > integer. >> > >> > "The ratiio 4/3 is FIXED BIN," >> > >> > No, its FIXED DECIMAL (1,0)... >> >> No it isn't. 4/3 yields 1.33... to 15 digits, >> and is of precision (15,14) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- 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: PL/I integers: Constant Identifiers
If you declare a variable with maximal precision for one compiler and later compile it on a compiler with longer maximal precision, you get digits (bits) after the decimal (binary) point, Is it your position that FIXED variables are integers in one compiler but not in the other? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Wednesday, September 9, 2020 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I integers: Constant Identifiers From: "Seymour J Metz" Sent: Monday, September 07, 2020 5:33 AM > PL/I doesn't have integers. It does. Believe it or not, the constants 4 and 3 that you wrote in the next sentence are decimal INTEGERS. > The ratiio 4/3 is FIXED BIN, > with some number of bits after the binary point. No. The division of DECIMAL constants can never produce a BINARY result. See the result of 4/3 appended to the program. INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Saturday, September 5, 2020 11:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Constant Identifiers On Sat, 5 Sep 2020 08:13:42 +1000, Robin Vowels wrote: > >As for writing formulas, I prefer to follow a well-known formula, thus: > >volume = 4/3 * 3.14159 * radius**3 > Beware! Than might left-associate as: volume = ( 4/3 ) * 3.14159 * radius**3 ... and the quotient of integers, 4/3, is 1. >However, if I'm interested in efficiency, I'd prefer > >volume = 4 * 3.14159E0 / 3 * radius**3 > ... (and correct.) -- 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 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- 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: PL/I and decimal integers (was Constant Identifiers)
From: "Seymour J Metz"
Sent: Monday, September 07, 2020 4:30 AM
The default type for 3 and 4 is FIXED BINARY.
Definitely NOT.
3 and 4 are decimal digits.
PL/I does not have an integer type,
It does.
but the DIVIDE() BIF can be used to do an integer divide, and assigning a
quotient to a FIXED BIN(foo,0) variable may do what you want,
depending on precision issues.
From: IBM Mainframe Discussion List on behalf of Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, September 6, 2020 9:07 AM
On Sun, 6 Sep 2020 17:25:45 +1000, Robin Vowels wrote:
Beware! Than might left-associate as:
volume = ( 4/3 ) * 3.14159 * radius**3
... and the quotient of integers, 4/3, is 1.
No it's not. 4/3 yields 1.33.. to 15 digits in PL/I.
You're thinking of FORTRAN.
And C:
662 $ cat typetest.c
#include
int main() {
printf( "%10.6f\n", 4/3 * 3.14159 );
printf( "%10.6f\n", 4.0/3 * 3.14159 ); }
663 $ gmake typetest & ./typetest
cc typetest.c -o typetest
3.141590
4.188787
It ought to depend on the types of the operands of the polymorphic
operator, '/'. What are the default types of '4' and '3'? Does PL/I
entirely lack an integer divide?
The Language Ref. properly cautions that a constant declaration may
be necessary to control the constant types.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I integers: Constant Identifiers
From: "Seymour J Metz" Sent: Monday, September 07, 2020 5:33 AM PL/I doesn't have integers. It does. Believe it or not, the constants 4 and 3 that you wrote in the next sentence are decimal INTEGERS. The ratiio 4/3 is FIXED BIN, with some number of bits after the binary point. No. The division of DECIMAL constants can never produce a BINARY result. See the result of 4/3 appended to the program. INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Saturday, September 5, 2020 11:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Constant Identifiers On Sat, 5 Sep 2020 08:13:42 +1000, Robin Vowels wrote: As for writing formulas, I prefer to follow a well-known formula, thus: volume = 4/3 * 3.14159 * radius**3 Beware! Than might left-associate as: volume = ( 4/3 ) * 3.14159 * radius**3 ... and the quotient of integers, 4/3, is 1. However, if I'm interested in efficiency, I'd prefer volume = 4 * 3.14159E0 / 3 * radius**3 ... (and correct.) -- 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 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I support of vector instructions?
No source change? Certainly the compiler could interpret FIXED BIN as FIXED BIN(127,0), but if I've coded, e.g., FIXED BIN(60,3), I would hope that the compiler would only use a doubleword unless and until I changed the source and recompiled. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Attila Fogarasi Sent: Wednesday, September 9, 2020 2:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I support of vector instructions? Enterprise PL/I 5.2 supports ARCH(12) so has your desired vector instruction support. For completeness, so do Cobol 6.2, XL/C 2.3 and Java 8.5. Again no source code change in PL/I is needed, just recompile with ARCH(12) option. Really sad that IBM doesn't publicize these features better vector usage can cut cpu and elapsed time dramatically (I've seen 80% reduction for intensive programs). Great reason to upgrade the hardware and compilers :) On Wed, Sep 9, 2020 at 3:59 PM Attila Fogarasi wrote: > For greater precision Enterprise PLI supports the hardware Decimal > Floating Point which is enabled with the compiler option of FLOAT(DFP), > this then changes all the DECIMAL FLOAT data declarations to be DFP > allowing maximum 34 digits (and exact decimal precision, important for > financial applications). The PL/I language itself is unchanged, so > existing source code switches to using DFP with a recompile (though changes > in DCL might be desirable). Vector DFP is part of ARCH(12) which came with > z14. So Enterprise PLI fully supports it already, best I can tell, but > doesn't highlight such support in the doc. I do DFP in assembler as I > couldn't wait for the compilers to add support and also want finer control > (the devil is in the details). > > On Wed, Sep 9, 2020 at 2:53 PM Seymour J Metz wrote: > >> Has IBM announced an intention to support the vector instructions to >> allow more precision for FIXED DEC and FIXED BIN in PL/I? Are there other >> vendors that support greater precision? >> >> >> -- >> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I Division (was Constant Identifiers)
From: "Joe Monk" Sent: Monday, September 07, 2020 1:05 PM "No it isn't. 4/3 yields 1.33... to 15 digits, and is of precision (15,14)" Depends on RULES(IBM) or RULES(ANS). If its RULES(IBM) it will never be integer division. If its RULES(ANS) and the operands are unscaled, then it will be integer division. No it doesn't. See results appended to program. INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ On Sun, Sep 6, 2020 at 7:34 PM Robin Vowels wrote: On 2020-09-07 09:35, Joe Monk wrote: > "PL/I doesn't have integers." > > Sorry Shmuel, youre incorrect. > > FIXED BINARY (15,0) is a 2 byte integer and FIXED BINARY (31,0) is a 4 > byte > integer. > > "The ratiio 4/3 is FIXED BIN," > > No, its FIXED DECIMAL (1,0)... No it isn't. 4/3 yields 1.33... to 15 digits, and is of precision (15,14) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I support of vector instructions?
AFAIK, the vector instructions don't support more than 128 bits, so even if I need more I won't get it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Wednesday, September 9, 2020 3:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I support of vector instructions? On 2020-09-09 14:53, Seymour J Metz wrote: > Has IBM announced an intention to support the vector instructions to > allow more precision for FIXED DEC and FIXED BIN in PL/I? FIXED DECIMAL gives you up to 31 digits. FIXED BINARY gives you up to 63 bits. How much do you need? > Are there > other vendors that support greater precision? -- 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: PL/I Integer arithmetic. (was: Constant Identifiers)
- Original Message - From: "Seymour J Metz" Sent: Monday, September 07, 2020 3:02 PM Subject: Re: Constant Identifiers 4/3 yields 1.3, 04/3 yields 1332, ... Rubbish. 4/3 yields 1.33 INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ However, DIVIDE(4,3,16,15) yields 1.3...2 to 15 digits No, it yields 1.33 From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Sunday, September 6, 2020 7:58 PM Subject: Re: Constant Identifiers From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Sunday, September 06, 2020 1:33 PM On Sat, 5 Sep 2020 08:13:42 +1000, Robin Vowels wrote: As for writing formulas, I prefer to follow a well-known formula, thus: volume = 4/3 * 3.14159 * radius**3 Beware! Than might left-associate as: volume = ( 4/3 ) * 3.14159 * radius**3 "might"? Evaluation MUST proceed left to right. So, whether it is written as 4/3 or (4/3), the division will be done first. ... and the quotient of integers, 4/3, is 1. As I indicaed before, 4/3 yields 1.333.to 15 digits. However, if I'm interested in efficiency, I'd prefer volume = 4 * 3.14159E0 / 3 * radius**3 ... (and correct.) Yes, it's correct, but I wrote it that way in order to avoid unnecessary conversions and arithmetic in fixed-point. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- 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: PL/I Integer arithmetic (was: Constant Identifiers)
From: "Seymour J Metz" Sent: Monday, September 07, 2020 4:13 PM PL/I has never had integers. It always has had integers. The arithmetic rules for scaled fixed point are different from those for integers. In integer arithmetic, (4/3)*6 is 6 That's not the result you get in PL/I. Yes it is, with declarations as shown, as I said before, . Under IBM rules: %PROCESS RULES(IBM); INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ And under Rules (ans): %PROCESS RULES(ANS); INTEGER_DIVISION: PROCEDURE OPTIONS (MAIN); DECLARE (A, B) FIXED DECIMAL (15); A = 4; B = 3; PUT (4/3); PUT (A/B); PUT ( (A/B) * 6 ); END INTEGER_DIVISION; /* RESULTS: 1.33 1 6 */ As you can see, the results are the same under IBM and ANS rules. From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Sunday, September 6, 2020 7:06 PM Subject: Re: Constant Identifiers - Original Message - From: "Seymour J Metz" Sent: Monday, September 07, 2020 5:33 AM PL/I doesn't have integers. PL/I has always had integers. The ratiio 4/3 is FIXED BIN, No it not. It is FIXED DECIMAL -- as I said a few days ago. And it hasn't changed since. with some number of bits after the binary point. DECIMAL digits after the decimal point, because the reault is FIXED DECIMAL, not binary. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- 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: New listening port for ftp
Thank you, Attila. This clears up my doubt with the slash symbol in the parm. On Tue, Sep 8, 2020 at 5:27 PM Attila Fogarasi wrote: > You have to precede the parm with a "/" ... for LE-conforming programs the > LE options appear on the JCL EXEC PARM='LEruntimeparm/programparms' ... so > you code '/-PORT 9921' ... the joys of LE. Getting CEE error msg is a big > hint :) > > On Wed, Sep 9, 2020 at 12:48 AM Roberto Halais > wrote: > > > Listers: > > > > I am implementing a second FTP stc and I want it to listen on port 9921. > > > > The FTPD proc listens on port 21 by default. > > > > I read somewhere that you could specify //FTPS EXEC PGM=FTPD,PARM=(-PORT > > 9921) > > but I get: CEE3611I The run-time option -PORT was an invalid run-time > > option. > > > > How do I specify a different listening port for the stc? > > > > Couldn't find documentation on it. > > > > Thank you for any hints. > > > > -- > > 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 > -- Politics: Poli (many) - tics (blood sucking parasites) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZCX task monitoring, anyone?
Yuksel Thank you for that information and I'm sorry I haven't responded sooner (other work took precedence, as is so often the case). Your modification to the 'run' command has worked exactly as required. I now have cadvisor running on my zcx system and overall CPU utilisation is down to a much more reasonable 5-6% - a very welcome change! Thanks you again Regards Sean On Wed, 2 Sep 2020 at 22:09, Yuksel Gunal wrote: > Hi Sean, > > cAdvisor polls for metrics once a second by default. Though I have not > seen such high CPU utilization with the default setting, it is worth to run > cAdvisor with a different setting, one that you can define explicitly when > you start cAdvisor. I'd recommend that you try a 10s or 15s interval and > see if either helps. To do that, you need to specify the > "--housekeeping_interval" parameter. Here is how you'd do it on zCX (sets > it to 10 seconds): > > docker run -v /:/rootfs:ro -v /var/run:/var/run:ro -v /sys:/sys:ro -v > /var/lib/docker/:/var/lib/docker:ro -v /dev/disk/:/dev/disk:ro -p 8080:8080 > -d --network monitoring --name=cadvisor ibmcom/cadvisor-s390x:0.33.0 > cadvisor --housekeeping_interval=10s > > Note that I modified the instructions by adding "cadvisor > --housekeeping_interval=10s" > > Also, Prometheus polls cAdvisor, but cAdvisor's data collection is not > triggered by Prometheus polling. It has its own polling cycle and it keeps > the metrics in memory. When Prometheus polls cAdvisor, it returns the last > set of collected metrics from memory. > > Yuksel Gunal > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I support of vector instructions?
On Wed, 9 Sep 2020 17:16:22 +1000 Robin Vowels wrote: :>On 2020-09-09 14:53, Seymour J Metz wrote: :>> Has IBM announced an intention to support the vector instructions to :>> allow more precision for FIXED DEC and FIXED BIN in PL/I? :>FIXED DECIMAL gives you up to 31 digits. :>FIXED BINARY gives you up to 63 bits. :>How much do you need? Never more than 16M. Or 4 computers worldwide. -- 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
Re: can DIE routines invoke macro's using linkage=system
If it supports being disabled, why not|? On Tue, 8 Sep 2020 20:47:30 -0400 Joseph Reichman wrote: :> :> :>thanks -- 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
Re: PL/I support of vector instructions?
On 2020-09-09 14:53, Seymour J Metz wrote: Has IBM announced an intention to support the vector instructions to allow more precision for FIXED DEC and FIXED BIN in PL/I? FIXED DECIMAL gives you up to 31 digits. FIXED BINARY gives you up to 63 bits. How much do you need? Are there other vendors that support greater precision? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: can DIE routines invoke macro's using linkage=system
Got it looked if the macro has to be enabled for interrupts thanks > On Sep 9, 2020, at 1:49 AM, Jim Mulder wrote: > > The documentation for each macro has a section labeled > "Environment". Is there a particular macro for which you have > read the documentation and you are unable to understand it? > > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > Poughkeepsie NY > > "IBM Mainframe Discussion List" wrote on > 09/08/2020 08:47:30 PM: > >> From: "Joseph Reichman" >> To: IBM-MAIN@LISTSERV.UA.EDU >> Date: 09/09/2020 01:40 AM >> Subject: can DIE routines invoke macro's using linkage=system >> Sent by: "IBM Mainframe Discussion List" >> >> >> >> thanks > > > > -- > 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: PL/I support of vector instructions?
Enterprise PL/I 5.2 supports ARCH(12) so has your desired vector instruction support. For completeness, so do Cobol 6.2, XL/C 2.3 and Java 8.5. Again no source code change in PL/I is needed, just recompile with ARCH(12) option. Really sad that IBM doesn't publicize these features better vector usage can cut cpu and elapsed time dramatically (I've seen 80% reduction for intensive programs). Great reason to upgrade the hardware and compilers :) On Wed, Sep 9, 2020 at 3:59 PM Attila Fogarasi wrote: > For greater precision Enterprise PLI supports the hardware Decimal > Floating Point which is enabled with the compiler option of FLOAT(DFP), > this then changes all the DECIMAL FLOAT data declarations to be DFP > allowing maximum 34 digits (and exact decimal precision, important for > financial applications). The PL/I language itself is unchanged, so > existing source code switches to using DFP with a recompile (though changes > in DCL might be desirable). Vector DFP is part of ARCH(12) which came with > z14. So Enterprise PLI fully supports it already, best I can tell, but > doesn't highlight such support in the doc. I do DFP in assembler as I > couldn't wait for the compilers to add support and also want finer control > (the devil is in the details). > > On Wed, Sep 9, 2020 at 2:53 PM Seymour J Metz wrote: > >> Has IBM announced an intention to support the vector instructions to >> allow more precision for FIXED DEC and FIXED BIN in PL/I? Are there other >> vendors that support greater precision? >> >> >> -- >> 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: PL/I support of vector instructions?
For greater precision Enterprise PLI supports the hardware Decimal Floating Point which is enabled with the compiler option of FLOAT(DFP), this then changes all the DECIMAL FLOAT data declarations to be DFP allowing maximum 34 digits (and exact decimal precision, important for financial applications). The PL/I language itself is unchanged, so existing source code switches to using DFP with a recompile (though changes in DCL might be desirable). Vector DFP is part of ARCH(12) which came with z14. So Enterprise PLI fully supports it already, best I can tell, but doesn't highlight such support in the doc. I do DFP in assembler as I couldn't wait for the compilers to add support and also want finer control (the devil is in the details). On Wed, Sep 9, 2020 at 2:53 PM Seymour J Metz wrote: > Has IBM announced an intention to support the vector instructions to allow > more precision for FIXED DEC and FIXED BIN in PL/I? Are there other > vendors that support greater precision? > > > -- > 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
