Re: REXX vs other languages
On 2024-04-24 00:41, Paul Gilmartin wrote: On Tue, 23 Apr 2024 14:07:05 +, Schmitt, Michael wrote: Be sparse and elegant but not rococo. I prefer: 'A' B to (the equivalent): 'A ' || B The latter seems to cater to the expectations of PL/I or some other language. Catenation with || is PL/I and other languages. But I confess to an obsession with performance. Function call/return is costly, Catenation can be costly, because either or both operands need to be moved. In XPL, both operands are moved, except when the first operand is at the top of the free area. so I'll use: PARSE VAR A . . X . rather than (the sparser?): X = SUBWORD( A, 3 ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX vs other languages
On 2024-04-22 02:13, Paul Gilmartin wrote: On Mon, 22 Apr 2024 01:52:14 +1000, Robin Vowels wrote:o ... One would not use as variable such common keywords as mentioned above. The real advantage is that one doesn't need to keep in mind all those uncommonly-used words that might be used as variable names, somewhat the opposite. If the keywords are reserved, the processor will inform the programmer of misuse. Probably, but why waste time and effort changing the program and re-compiling? Another advantage of unreserved words is that the addition of a new keyword into the language does not invalidate any existing program. A processor can have an "oracle" that always correctly divines the programmer's intent, as PL/I does. But in a single Rexx program, the same symbol can be a variable in one instruction but a keyword in the next, with no syntax error but unexpected result. Doesn't sound like sensible design. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX vs other languages
On 2024-04-22 00:05, Seymour J Metz wrote: While PL/I has no reserved words, it is considered bad form to use a keyword as an entry or variable name. The same principle applies to Rexx; using, e.g., DO, ELSE, END, EXIT, IF, ITERATE, OTHERWISE, PROCEDURE, THEN, WHEN, as a variable name can make the code hard to read. One would not use as variable such common keywords as mentioned above. The real advantage is that one doesn't need to keep in mind all those uncommonly-used words that might be used as variable names, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX vs other languages
On 2024-04-21 04:22, Paul Gilmartin wrote: On Sat, 20 Apr 2024 19:50:56 +0200, Rony G. Flatscher wrote: ... There are *no* reserved words in Rexx like in many other languages. (This alleviates one to have to learn them by heart. But more importantly, should the language get additional keywords over time I disagree. Although it's context-sensitive. But ITERATE and LEAVE are keywords within DO loops, Are you confusing reserved words and keywords? Keywords can be reserved words that cannot be used for other purposes, as in COBOL. In some languages, such as PL/I, keywords still have a meaning in the language, but can be used for other purposes such as identifiers. Such words are not reserved words. which may not be intuitively obvious. Otherwise they would be commands. RETURN is generally a keyword. And THEN is a keyword in an IF. they would not break existing Rexx programs that happen to use them already, unlike other programming languages.) Not true. When I first learned Rexx, A='XYZ'B was legal. Later, it became a syntax error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX vs other languages WAS: Rexx numeric digits and scientific notation question
On 2024-04-21 15:38, Paul Gilmartin wrote: On Sat, 20 Apr 2024 23:58:18 -0500, Bruce Hewson wrote: I use "cnt" for my loop counters. I stopped using FORTRAN style single character variable names when I started coding in REXX. I thought FORTRAN allowed six. It did. Now it allows many more. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
On 2023-11-18 03:38, Bernd Oppolzer wrote: Sorry for jumping in VERY late. If you have something like DCL X CHAR (6); X = DATE; then you will get strange results, because DATE is not recognized as the well-known builtin function DATE which returns the current date. But instead it is a DECIMAL FLOAT(6) variable Not when you specify explicit declarations. In his case, the identifier is marked as not declared, and it is treated as a compile-time ERROR. The default in PL/I (F) days for undeclared identifiers whose initial letter was A-H and O-Z was FLOAT BINARY. with an undefined value (given the "normal" default rules, inherited from FORTRAN, which defines an undefined variable depending on its first letter ... and, of course, if you don't have the more modern compiler options which prevent you from using undefined variables etc.). Now, if you want the compiler to use the builtin function DATE instead of this undefined variable, you have two choices: - declare DATE as a BUILTIN function DCL DATE BUILTIN; X = DATE; - put parantheses after DATE; that is: X = DATE (); this way, DATE is known to be the BUILTIN function "by context". Both variants will do. Same goes for all other builtin functions without arguments. 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: PL/I question
The attribute BUILTIN can be used only for a name that is a built-in function. It overrides any prior declaration if the name as a variable or label etc in an outer block. On 2023-11-16 05:33, Steve Beaver wrote: BUILTIN is a way to tell the compiler that what ever something like SUBSTR doesn’t need to be resolved outside of the object Sent from my iPhone No one said I could type with one thumb On Nov 15, 2023, at 11:33, Binyamin Dissen wrote: A PL/I source code member has DCL foobar BUILTIN and must be compiled with RULES(LAXDCL) I see no reference to FOOBAR as a function call. My question is if FOOBAR was invoked, what does the BUILTIN clause do? A different calling sequence? Looking for an internal label? -- Binyamin Dissen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
BUILTIN is used when, for example, an identifier that is the same as the name of a BUILT-IN function has been used as a variable. Suppose that you want to use that built-in function in an inner block. Then you declare it as BUILTIN. E.G. declare sqrt builtin; This overrides the declaration in the outer block. On 2023-11-16 04:34, Binyamin Dissen wrote: A PL/I source code member has DCL foobar BUILTIN and must be compiled with RULES(LAXDCL) I see no reference to FOOBAR as a function call. My question is if FOOBAR was invoked, what does the BUILTIN clause do? A different calling sequence? Looking for an internal label? -- Binyamin Dissen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I early compilers performance issues
There may have been issues with LCS (Large Core Storage). Our site had 128K core with 1 Mb LCS. OS/360 took up almost all the core storage. Access to LCS was much slower than to core store. We therefore made local PL/I variables static (except for arrays, which typically had variable dimensions). On 2023-09-07 13:32, Bernd Oppolzer wrote: Thinking a little bit more about this: the insurance company used auto variables heavily, BUT: until the 2010 time frame, they didn't allow (or: suggested not to use) INTERNAL PL/1 procedures !! Instead they had some home grown macros based on label variables, which worked much the same like procedure calls, but the "program blocks", which were built using these macros - of course - didn't have local variables; all variables are GLOBAL. Using this technique, performance issues during procedure startup are no problem, of course. In 2010, one of my co-workers (and a friend of mine) checked out the performance of these "program blocks" and found out that the heavy use of label variables COMPROMISES the optimizing strategies of the modern compilers, so that now the "program blocks" based on label variables are MUCH SLOWER than original PL/1 procedures. That's why the company now changed the recommendation and asked all programmers to change the programs from the old "program blocks" to normal procedures (when doing maintenance to the programs). This led to significant better performance in some cases (especially in large Batch programs with many "program blocks"). There are still many programs using the old "program blocks", and we are now thinking about forcing the transformation process in the next months. When compiling a program using the old feature, you get a return code of 8 and a compiler message, but the code is produced, anyway. Kind regards Bernd Am 07.09.2023 um 05:13 schrieb Bernd Oppolzer: Am 07.09.2023 um 01:40 schrieb Leonard D Woren: Michael Stein wrote on 9/6/2023 3:45 PM: [...] PL/1 F level subroutine calls did a getmain/freemain for each subroutine call. Too much overhead to call even one subroutine for each of 30K records on a 360/91 & MVT. Well, my recollection is that if you had only Static storage, no Automatic storage, it didn't do a GETMAIN. Or was that an enhancement in the new PL/I compiler? Was that PLIX? Yeah, not using stuff for decades can cause memory fade. /Leonard I first came into contact with PL/1 in the end of the 1980s at the beforementionend insurance company. At that time, they had the V2.3 optimizer (IIRC), and it produced pretty amazing code. I was asked to do PL/1 classes for the developers there. This company made (and still makes) heavy use of automatic storage and tried to code all modules "naturally reentrant", that is: no modified static storage. So the problems with getmain/freemain at procedure startup and end must have been long gone. That company started with PL/1 in the beginning of the 1980s, before that is was an ASSEMBLER only shop. (C came later, from 1992 on). 1992 (and 1994 again) I was asked to do a dump analysis class in another PL/1 company. They indeed had DEFEAULT RANGE(*) STATIC; in almost every program. I didn't understand the reason at that time and thought is was for dump reading, because static variable (in the STATIC CSECT which is part of the load module) are much easier to find than auto variables (living in the stack). But now I have the impression that this could have simply been a performance issue in the beginning. Kind regards Bernd -- 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: Is the IBM Assembler List still alive
Please do not use this subject heading, Please change it to what you are talking about. On 2023-09-05 22:53, Bob Bridges wrote: Hey, look at that! I never knew why the famous IEFBR14 was so named; now I guess maybe I do, though I won't be guessing after I look up the BR instruction). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Microsoft office
It's for this very reason that I still maintain at least one computer with Windows 3.1 and Word 1.1a. Everything works, including formulas. And it came with a great manual. As well as for preparing documents generally, I used Word 1.1a for automatically preparing indexes for books. Trying to convert to Word 6 was a disaster; for example, changing from footnotes to end notes lost the entire document. There were minor problems also with Word 6, such as different meanings of keystrokes for the extra characters using the ALT key. On 2023-08-20 04:03, Radoslaw Skorupka wrote: W dniu 15.08.2023 o 17:47, Steve Beaver pisze: One thing that absolutely scares the hell out of me is converting Office 2010 To any of the new Office Products, Has anyone converted? What Problems did you have? (yes, it is off-topic, but I couldn't resist) Yes, I did. Conversion from 2010 to any newer version was not a pain. But NOTE: the more advanced features you use the more pain because of incompatibilities, dropped suport, etc. The most painful migrations I remember: 1. Word 2.0 to 6.0 2. Word 2000 to XP 3. Word XP to 2003 4. Word 2003 or older to 2007 Ad 1. A lot of incompatibilities, especially related to PL version. Polish letters (ąćęłńóśćżź) converted to "US-eng" codetable equivalents. 2. Dropped support for diagrams creator. I had to recreate it from scratch. 3. New errors which resulted abends during typo-check. 4. Completely changed user interface with almost no new features. Very same functions need to searched. Other "features": suddenly dropped support for Word 2.0 files. You even cannot open it! suddenly dropped support for RTF files. suddenly dropped/changed plugins like Equation Editors, etc. changed functions like indexing, styles, contents, etc. etc. suddenly dropped/revolutionized pictures embedded (not bitmaps, just drawings like squares, circles, arrows, etc. ) This is only part of "advantages" mostly related to Word. Hints: 1. Don't try to use advanced features if you really can avoid it. 2. Open all your documents and all the features like drawings or embedded objects. 3. If you can simply keep your old version! Yes, you can still have your ancient version of Office on you PC. Just use VirtualBox or other hypervisor and keep one or few virtual machines. Check your license terms, but if you had older version then usually you did not lost the license. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I Opt. Compiler V2 manuals?
On 2023-03-20 11:32, Peter Stockdill wrote: Hi Robin, The first four are direct links to the BookManager book files. The fifth should have been: http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_Proble m_Determination_Dec87.pdf As I said, the last link is OK. The first four links are bad. jibberish is shown, like we are looking at a character print of some binary file. Cheers, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Robin Vowels Sent: Monday, 20 March 2023 8:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I Opt. Compiler V2 manuals? Except for the last, the links are incomplete. On 2023-03-20 08:06, Peter Stockdill wrote: https://publib.boulder.ibm.com/epubs/book/ibmop002.boo https://publib.boulder.ibm.com/epubs/book/ibmol004.boo https://publib.boulder.ibm.com/epubs/book/ibmom002.boo https://publib.boulder.ibm.com/epubs/book/ibmot001.boo http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_ Problem_Determination_Dec87.pdf -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I Opt. Compiler V2 manuals?
Except for the last, the links are incomplete. On 2023-03-20 08:06, Peter Stockdill wrote: https://publib.boulder.ibm.com/epubs/book/ibmop002.boo https://publib.boulder.ibm.com/epubs/book/ibmol004.boo https://publib.boulder.ibm.com/epubs/book/ibmom002.boo https://publib.boulder.ibm.com/epubs/book/ibmot001.boo http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_Problem_Determination_Dec87.pdf -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Markup languages
I used an early version of Word for Windows for writing a 1,000-page document. No mark-up language required. It also produced automatically the index. When I wanted to put more entries in the index, it was a minute's work. Then press F8 and the entire index was regenerated as a Word document in about two minutes. On 2022-12-27 19:23, Colin Paice wrote: It may be horses for courses... 1. What needs to be supported Windows/Mac/Linux? 2. Do you want a few page document or a 200 page document and imbed other sections 3. Do you want to be able to print chapters, or just the whole book. 4. Do you table of contents 5. Do you want change bars to show you what has changed 6. What is your output - PDF, one HTML document - an HTML tree? 7. Number of concurrent maintainers so 1) & 2) are relevant I run on Linux, which limits my choice of tools. I've used Latex to write a 200 page document. If you think of Scriptvs, and book master, you'll get the idea. You can write macros to provide complex formatting. It allows you to have change bars to show you what's changed. You have to add them manually. I use reText as editor, and real time review You can tell how old I am when my brain thinks of ":p:h1 " when marking up a document Colin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on writing PL/I to use EXEC PARM/PARMDD
On 2022-11-21 05:46, Farley, Peter wrote: Thanks to all for the PL/I advice, and yes, I do know they changed the name from 1 to I a long time ago, The language has always been called PL/I, from IBM's first LRM C28-6571. (after, of course, from earlier temporary names such as NPL) but I didn't much like that rename starting from when they did it. What was wrong with using a plain Arabic numeral? Then again I use the Roman numeral III for my full name since I am the third generation with that name (and my son is the IV'th). We are all sometimes a bit schizophrenic in our thinking. Anyway, thanks again to all for the gentle advice. Appreciated. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on writing PL/I to use EXEC PARM/PARMDD
On 2022-11-21 02:29, Steve Smith wrote: Not necessarily. My example code (which preceded) comes straight from the manual, and is required when main PROCEDURE statement is as I showed, namely, M: PROC (PARAM) OPTIONS (MAIN); DECLARE PARAM CHARACTER(100) VARYING; Assuming using an LE compiler, the EXECOPTS compile option controls this. It doesn't. Read the manual. What I wrote applies then EXECOPS is not used. On Sun, Nov 20, 2022 at 2:30 AM Robin Vowels wrote: The string passed to the main procedure needs to start with a slash, because everything up to and including the slash is omitted when passed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on writing PL/I to use EXEC PARM/PARMDD
The string passed to the main procedure needs to start with a slash, because everything up to and including the slash is omitted when passed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on writing PL1 to use EXEC PARM/PARMDD
M: PROC (PARAM) OPTIONS (MAIN); DECLARE PARAM CHARACTER(100) VARYING; On 2022-11-20 17:20, Farley, Peter wrote: It's been quite a long while since I had a finger in any PL1 code, but I now have a small PL1 side project I need some help with. I have a question about how to handle not only the "standard" EXEC PARM of up to 100 bytes, but also how to handle the newer EXEC PARMDD option which allows up to 32760 bytes of PARM data in a PL1 OPTIONS(MAIN) procedure. In COBOL the quasi-standard I have been using is this structure in the LINKAGE section of a main program that expects PARM/PARMDD input: LINKAGE SECTION. 01 PARM-AREA. 05 PARM-LEN PIC S9(4) BINARY. 05 PARM-DATA. 10 PARM-X OCCURS 0 TO 32760 DEPENDING ON PARM-LEN PIC X. That structure occupies no storage in the COBOL program, and instead is accessed directly by using the R1 address passed to the COBOL program by the "EXEC PGM=" process. How do I define a similar vehicle for PARM data in current releases of Enterprise PL1 (I have the V5.3.0 version available to me for this project)? Is there a way to do it with a CHAR (*) VARYING BASED variable? Or have I lost all sense of what is and is not possible in PL1? Please be gentle, it has been a very *long* time since I have done any actual PL1 coding, and a lot of memory cells from that bygone era have been lost to bit rot. Any RTFM's or url pointers much appreciated. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler courses
On 2022-09-27 12:14, Hank Oerlemans wrote: My extremely unhelpful advice ? Chuck them in the deep end ! When I was 20 my lovely German boss said write a channel program to scan the CA-1 TMC for some criteria. Many weeks later with BALR and USING and whatever and a hardcopy IPCS manual it worked and that's the most complex thing I've ever written. Who was that kid ? Never got around to BXLE - which was, reputedly, worthy of a merit badge in wider circles. Despite the S/360 being a "safe" machine, with hardware check for fixed-point overflow (among others of that ilk), BXLE and BXH were the achilles heels of the system, because overflow was ignored. Even BCTR was not "safe". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: is there any documentation on using the new 64 bit instructions?
Try John Ehrman's Assembly Language Programming On 2022-06-29 00:12, Colin Paice wrote: I've been working on calling an (amode 31) assembler program from a 64 bit C program, and have been struggling.Is there is a good guide on how to use these new instructions? For example 1) I've found you need to use a LLGTR R1... instruction to clear the register before using a L R1... because without it the high part of the register will have some 64 bit rubbish in it 2) I used BAKR R14,0 PR But it kept returning in amode 24 bit mode. It needs BSM 14,0 before the BAKR.__ The POP tells you all about the instructions - but not how to use it. The z/OS doc says use BACK/PR without mentioning the BSM, so this is not completely trustworthy. _ Is there a better place to ask? Colin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tabulating Machines (was "... z114")
On 2022-05-30 20:33, Seymour J Metz wrote: I've only seen a 407; did the boards for the other 40x machines have the same form factor? You could open the door an wire the board without removing it; I can't imagine wanting to do so. When a minor change was required to the wiring, the could be done without pulling the board right out. While 80-80 listing was certainly a standard board at every shop I heard of, 80-80 listing was never done at our site, for the very reason that spaces needed to be introduced between numbers, and because over-punched signs needed 2 columns (Y above a digit was printed as plus and the digit, X above a digit was minus and the digit). AFAIK the most common task for the 507 was printing reports with control breaks and sub-totals. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: my new z114
On 2022-05-29 01:53, Joe Monk wrote: I also wanted to ask if anyone could share the proper 3 phase to single phase wiring for the power cable... What? Usually a transformer is required. Three phase requires three wires. If a neutral is available, a load can be connected between the neutral and one of the wires of the three phase cable. Be aware that the voltages between the wires of the three phase cable are high, and can be lethal. You need the right power cable!!! The connections are in the z114 redbook. Joe On Sat, May 28, 2022 at 9:28 AM Enzo D'Amato wrote: This is about what I expected in terms of CPU and memory, but I have no idea what happened with the expansion cards. I almost certainly will not use 18 ficon ports anyway, so I am not too upset about those ports. Either way, I will ask the seller what happened with the extra channel cards. I also wanted to ask if anyone could share the proper 3 phase to single phase wiring for the power cable (I know the z114 BPRs can take 220v single phase). I am checking the technical and physical planning guides for this information, but I would like to independently verify this information so that I don't fry my new machine. Thanks, Enzo Damato -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I
On 2022-03-31 03:25, Seymour J Metz wrote: Yes, range checking carries a performance penalty, and there have been arguments in the past about performance versus safety. I'm in the camp that believes that they should be enabled in any program where incorrect output would cause a problem or where there are security issues. An overrun is dangerous, since it can result in other data being destroyed without warning, and if those corrupted data are then used or printed, the results will be wrong -- again without warning. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I
On 2022-03-31 03:06, Jay Maynard wrote: ISTR that STRINGRANGE and STRINGSIZE carried a performance penalty, though it's been a very long time since I did PL/I. I would expect that the hit is small but measurable, and generally worth it. The overhead for STRINGSIZE is usually small, small enough to be trivial, since it requires a comparison between the declared length and the length of the string to be assigned. Typically that requires one each of L, C, and BC instructions. The overhead for SUBSTR requires more checking, since there are now two integer arguments that need to be tested. On Wed, Mar 30, 2022 at 10:54 AM Robin Vowels wrote: On 2022-03-31 01:42, Seymour J Metz wrote: > However, buffer overruns are characteristic of languages with no range > checking. Of course, you can write C in PL/I with, e.g, > (NOSTRINGRANGE) prefixes. No, the appropriate condition is STRINGSIZE. And that is disabled by default. STRINGRANGE is disabled by default also. It is always recommended to enable the STRINGSIZE condition. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
On 2022-03-31 02:38, Seymour J Metz wrote: Who does that leave? The obvious; your claim is untrue and it is you. Looks like you have egg on your face again. Put up or shut up. PL/I does not have computed GO TO. If it looks like a duck, quacks like a duck, it probably is a duck. Try: GO TO X(I); X(1): A = B; ... X(2): A = C; ... X(3): A = D; ... and try: GOTO (1, 2, 3), K 1 A = B ... 2 A = B ... 3 A = C ... Guess which one is FORTRAN and which is PL/I. It has LABEL arrays, which are more useful. There may be cases where a computed GO TO would be clearer if it exiasted, but good or bad, PL/I doesn't have it. Read what I wrote. I did; it's BS. More egg on your face. White space has noting to do with it. That's a perfect example of BS. In FORTRAN, DO 500 I=1.10 is an assignment statement because the blanks are not significant. In PL/I, DO I=1.10; is still a DO statement, because spaces are not allowed inside a variable name. That is irrelevant to whether the DO statement in PL/I was taken from FORTRAN. From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Tuesday, March 29, 2022 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I question On 2022-03-30 00:06, Seymour J Metz wrote: It's obvious that one of us doesn't know what he's talking about, And it's not me. Who does that leave? especially as you cited things that don't even exist in PL/I as being derived from FORTRAN. Put up or shut up. And you still haven't answered whether you seriouslyu believe thaat the FORTRAN DO resembles the PL/I DO more than the ALGOL FOR statement does. Read what I wrote. Your purported explanation of the difference in DO between FORTRAN and PL/I is ludicrous, because the rules for "white spacew" in FORTRAN and PL/I are very different. White space has noting to do with it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I
On 2022-03-31 01:42, Seymour J Metz wrote: However, buffer overruns are characteristic of languages with no range checking. Of course, you can write C in PL/I with, e.g, (NOSTRINGRANGE) prefixes. No, the appropriate condition is STRINGSIZE. And that is disabled by default. STRINGRANGE is disabled by default also. It is always recommended to enable the STRINGSIZE condition. From: IBM Mainframe Discussion List on behalf of Paul Gilmartin Sent: Wednesday, March 30, 2022 10:31 AM Subject: Re: PL/I question On Wed, 30 Mar 2022 14:53:57 +0100, Rupert Reynolds wrote: That's a common problem, certainly, but if we include the wider world of micros and minis, I'd bet that buffer overuns related to null-teminated strings (BLEAH!) are in the lead :-) Buffer overruns are hardly peculiar to null-temniated strinigs. Rather, they result from indolent programmers' neglecting to check the length before the move or the status after; using strcat() and sprinitf() instead of strncat and snprintf(); etc. What should be done in HLASM? Use unprotected MVCL, or define data types with explicit lengths and rely on macros to move data with protection? Should an attempted buffer overrun throw an exception? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FORTRAN comma
Hi David, I found this:- A missing punctuation mark in a guidance equation led to a much greater national embarrassment when the rocket carrying the Mariner 1 space probe exploded shortly after liftoff on July 22, 1962, in what is widely believed to the most expensive typographical mistake of all time. Some reports attributed the rocket failure to a misplaced decimal point, an extra semicolon or a comma that was entered in place of a period in the coded mathematical instructions that guided the steering systems on board the spacecraft. However, NASA investigators traced the cause of the accident to the omission of a single hyphen (or superscripted overbar) in the guidance control software, which transmitted a series of incorrect course correction signals that threw the vehicle off its flight trajectory. The range safety officer had no choice but to order the intentional detonation of the spacecraft less than five minutes after liftoff to prevent the vehicle from crashing into a populated area. The high-profile failure of the Mariner probe to reach its intended destination underscores the need for periodic proofreading, peer review analysis and rigorous testing for performance problems at all stages of computer coding and programming. The syntax of a programming language requires a highly specific sequence of symbols and characters to process information, specify external machine behavior and direct a computer to execute a set of commands. A simple typing error or misplaced character could preclude the operating system from translating coded language accurately, render an entire application useless, or lead to unpredictable or even disastrous consequences. There was intense political pressure to hasten the schedule to launch a planetary expedition ahead of the Soviet Union and to establish spaceflight supremacy. The single missing FORTRAN coding symbol was not detected during preflight preparations as a result of the accelerated timetable and was largely responsible for the loss of the first American spacecraft destined to explore another planet. The mission failure was a setback for interplanetary space exploration and dealt a significant blow both to national morale and to the prestige of the space administration at a time when the United States was losing the space race. When calculating the adjusted costs of research, development, training and construction, the total losses connected to the accident are estimated to exceed $620 million. Never in history has so much money or so many resources been squandered over the exclusion of a single punctuation mark. On 2022-03-30 01:31, David Spiegel wrote: Hi Robin, I searched, but, am not yet successful in finding it If I find it, I plan to let you know. Regards, David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FORTRAN comma
Hi David, Probably I have not read this article, but have seen discussions about the mistake. Do you have a specific reference to it? (I looked with google, without success). Thanks, Robin On 2022-03-30 00:22, David Spiegel wrote: Hi Robin You said: "... BTW, the change in format of the DO was essential in preventing the flaw in FORTRAN (which still exists) by which a period instead of the first comma changes the DO statement into an assignment statement. ..." Have you ever read the Datamation article regarding the comma which cost $15,00,000 (in the '60s)? Regards, David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
On 2022-03-30 00:06, Seymour J Metz wrote: It's obvious that one of us doesn't know what he's talking about, And it's not me. Who does that leave? especially as you cited things that don't even exist in PL/I as being derived from FORTRAN. Put up or shut up. And you still haven't answered whether you seriouslyu believe thaat the FORTRAN DO resembles the PL/I DO more than the ALGOL FOR statement does. Read what I wrote. Your purported explanation of the difference in DO between FORTRAN and PL/I is ludicrous, because the rules for "white spacew" in FORTRAN and PL/I are very different. White space has noting to do with it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
On 2022-03-29 17:42, Michael Stein wrote: On Fri, Mar 25, 2022 at 11:20:10AM +, Rupert Reynolds wrote: Vaguely related, can anyone comment on the assertions that PL/I was considered "too slow" back in the old days, and that it was "too verbose for writing system code"? Excuse me? MVS system macros are stuffed with its close relative, PL/S! I used PL/1 back in the MVT days, F level. My memory says that it did a getmain/freemain for each PL1 procedure call. That's correct. It was to obtain storage for non-static variables and to set up stuff for procedure entry. The storage was given up at procedure termination. So reading a file of students (30k+) you couldn't afford a procedure call in the path. It was ok to use them during init and term (which only happened once). This was a 360/91KK and 2314 disks... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
On 2022-03-29 22:46, Seymour J Metz wrote: I'm not going to mention all of them, but you obviously noticed that I mentioned DO. Then, it's obvious that you don't know what you are talking about. Are you seriously claiming that "DO K = 1 TO 10 BY 2;" looks more like "DO 10 K = 1, 10, 2 " than it does like "for K := 1 step 2 until 10 do"? Given that the PL/I language was derived from FORTRAN IV, and that the name of the language was FORTRAN VI, it is reasonable to assert that the PL/I version was derived from FORTRAN IV, and that the keyword 'TO' was only required to be added to the short form, and 'TO' and 'BY' to be added to the long form. PL/I went a lot further than FORTRAN IV: for example, multiple iterations were added, and, for example, the 'TO' component could be omitted. BTW, the change in format of the DO was essential in preventing the flaw in FORTRAN (which still exists) by which a period instead of the first comma changes the DO statement into an assignment statement. From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Robin Vowels [robi...@dodo.com.au] Sent: Monday, March 28, 2022 8:45 PM Subject: Re: PL/I question - Original Message - From: "Seymour J Metz" Newsgroups: bit.listserv.ibm-main To: Sent: Tuesday, March 29, 2022 10:47 AM Subject: Re: PL/I question You claimed that a lot of things came from FORTRAN that don'r look remotely like FORTRAN syntax, Name them. some of which look like Algol 60. A good example is the DO statement, which looks a lot more like an Algol for statement than a FORTRAN DO. Try DO 10 K = 1, 10 ->DO K = 1 TO 10; DO 10 K = 1, 10, 2->DO K = 1 TO 10 BY 2; Some of what you claimed came from FORTRAN doesn't even exist in PL/I. Name them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
- Original Message - From: "Seymour J Metz" Newsgroups: bit.listserv.ibm-main To: Sent: Tuesday, March 29, 2022 10:47 AM Subject: Re: PL/I question You claimed that a lot of things came from FORTRAN that don'r look remotely like FORTRAN syntax, Name them. some of which look like Algol 60. A good example is the DO statement, which looks a lot more like an Algol for statement than a FORTRAN DO. Try DO 10 K = 1, 10->DO K = 1 TO 10; DO 10 K = 1, 10, 2->DO K = 1 TO 10 BY 2; Some of what you claimed came from FORTRAN doesn't even exist in PL/I. Name them. --- 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 question
From: "Phil Smith III" Sent: Tuesday, March 29, 2022 5:56 AM My dad once told me that he'd seen a PL/I program in South America somewhere in which the language itself was Spanish-the keywords etc. So "si" for "if" (not to be confused with "yes"!) and "más hacer" for "else do", etc. I'm now suspecting this was done using the preprocessor. That is definitely done with the preprocessor. It was part of IBM's course in 1966. The keywords can be substituted with local language words. --- 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 question
On 2022-03-28 22:38, Seymour J Metz wrote: Oddly enough, you listed lots of bogus claims There are no bogus claims. but forgot one that is legitimate: the default attributes depending on variable names. Of course, in FORTRAN it's wired in, but the original PL/I defaults matched FORTRAN. I don't claim to have itemised every possible feature that came from various languages. They are OTOMH. The main point was that you are wrong in claiming that "FORTRAN had the least influence of the three", which is patently and demonstrably false. Yes, the I to N default for integers, and the rest real, came from FORTRAN, and while we're here, so did PL/I's DEFAULT statement (from FORTRAN's IMPLICIT). From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Robin Vowels [robi...@dodo.com.au] Sent: Monday, March 28, 2022 6:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I question On 2022-03-28 20:43, Seymour J Metz wrote: I'm fully aware of the initial name; the fact remains that IBM and SHARE looked at three languages, and that FORTRAN had the least influence of the three. Static storage came from FORTRAN. Edited input-output (format lists) came from FORTRAN. EXTERNAL came from FORTRAN. Function references came from FORTRAN. CALL statements came from FORTRAN. Computed GO TO came from FORTRAN. Remote formats came from FORTRAN Label parameters came from FORTRAN. Assignment statements came from FORTRAN. Implied DO came from FORTRAN. Data-directed I/O came from FORTRAN. FORMAT statements came from FORTRAN. DO statements came from FORTRAN. Most of the language derives from Algol 60 Dynamic arrays and scalars came from ALGOL. Block structure came from ALGOL. Explicitly allocated arrays did not come from ALGOL. Free source form came from Algol. Conditional statements came from Algol. No I/O came from Algol. Generic functions did not come from Algol. and COBOL, Data structures came from COBOL. Picture came from COBOL. Decimal came from COBOL. and the most obvious feature from FORTRAN has gone by the wayside. These new features were introduced in PL/I: BIT strings. scaled fixed binary. Varying-length strings. ALLOCATE-able variables. The means of detecting and intercepting run-time errors. integer overflow detection. subscript bounds checking. string range checking. preprocessor. From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Robin Vowels [robi...@dodo.com.au] Sent: Monday, March 28, 2022 4:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I question On 2022-03-28 19:10, Seymour J Metz wrote: Exaclly, especially since Algol 60 was one of the three languages folded into PL/I. FORTRAN, not Algol, was the starting-point for PL/I. It was even called FORTRAN VI. Features of both Algol and COBOL were incorporated into the language. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
On 2022-03-28 20:43, Seymour J Metz wrote: I'm fully aware of the initial name; the fact remains that IBM and SHARE looked at three languages, and that FORTRAN had the least influence of the three. Static storage came from FORTRAN. Edited input-output (format lists) came from FORTRAN. EXTERNAL came from FORTRAN. Function references came from FORTRAN. CALL statements came from FORTRAN. Computed GO TO came from FORTRAN. Remote formats came from FORTRAN Label parameters came from FORTRAN. Assignment statements came from FORTRAN. Implied DO came from FORTRAN. Data-directed I/O came from FORTRAN. FORMAT statements came from FORTRAN. DO statements came from FORTRAN. Most of the language derives from Algol 60 Dynamic arrays and scalars came from ALGOL. Block structure came from ALGOL. Explicitly allocated arrays did not come from ALGOL. Free source form came from Algol. Conditional statements came from Algol. No I/O came from Algol. Generic functions did not come from Algol. and COBOL, Data structures came from COBOL. Picture came from COBOL. Decimal came from COBOL. and the most obvious feature from FORTRAN has gone by the wayside. These new features were introduced in PL/I: BIT strings. scaled fixed binary. Varying-length strings. ALLOCATE-able variables. The means of detecting and intercepting run-time errors. integer overflow detection. subscript bounds checking. string range checking. preprocessor. From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Robin Vowels [robi...@dodo.com.au] Sent: Monday, March 28, 2022 4:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I question On 2022-03-28 19:10, Seymour J Metz wrote: Exaclly, especially since Algol 60 was one of the three languages folded into PL/I. FORTRAN, not Algol, was the starting-point for PL/I. It was even called FORTRAN VI. Features of both Algol and COBOL were incorporated into the language. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
On 2022-03-28 20:26, Seymour J Metz wrote: Yes, I meant VARYINGZ. Zero termination, no interpolation, the normal doubling in literals. Block entry *is* run time. I know. That's why I wrote "explicitly determined at run time". I was referring to ALLOCATE. Also, exempli gratia (e.g.) means for example; had that been a complete list I would have written id est (i.e.). From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Robin Vowels [robi...@dodo.com.au] Sent: Monday, March 28, 2022 5:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I question From: "Seymour J Metz" Sent: Monday, March 28, 2022 4:10 AM There are no troublesome characters. If it's CHARZ There's no such attribute. Do you mean VARYINGZ? then a '00'X marks the end of the string, as in C. Otherwise there is an explicit length that is the same regardless of what characters are in the string. The length may be determined at, e.g. compile time, block entry, or may be dynamic (VARYING). And it can be explicitly determined at run time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
- Original Message - From: "allan winston" Newsgroups: bit.listserv.ibm-main To: Sent: Saturday, March 26, 2022 1:26 PM Subject: Re: PL/I question From 1970 to 1972, I was in a shop that made the transition from PL/I F to the PL/I optimizing compiler. I would frequently use the LIST compiler option to look at the machine code generated and found that the PL/I F compiler generated quite poor code, frequently having to make a library call just to implement the SUBSTR function. By 1968, the SUBSTR function was implemented as in-line code in PL/I(F). If, however, STRINGRANGE was specfied, in-line code was not generated. In general, to avoid using subroutine calls, it was necessary to specify a minimum optinisation level of 1, in which case in-line code was generated. By contrast, the PL/I optimizing compiler generated very good machine code. --- 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 question
On 2022-03-28 02:45, Rupert Reynolds wrote: Related: how does LE handle strings with embedded troublesome bytes such as x'00'? And is it different between PL/I and C? Conventional strings in PL/I can contain any character. VARYINGZ strings are terminated with a character X'00'. I am reading the PL/I Programming Guide, Read the Language Specification, and check out VARYING and VARYINGZ. but it takes but I'm hoping there is an easy off-the-cuff answer. Most of my PL/I experience was before LE, you see. --- 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 question
From: "Seymour J Metz" Sent: Monday, March 28, 2022 4:10 AM There are no troublesome characters. If it's CHARZ There's no such attribute. Do you mean VARYINGZ? then a '00'X marks the end of the string, as in C. Otherwise there is an explicit length that is the same regardless of what characters are in the string. The length may be determined at, e.g. compile time, block entry, or may be dynamic (VARYING). And it can be explicitly determined at run time. --- 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 question
On 2022-03-28 19:10, Seymour J Metz wrote: Exaclly, especially since Algol 60 was one of the three languages folded into PL/I. FORTRAN, not Algol, was the starting-point for PL/I. It was even called FORTRAN VI. Features of both Algol and COBOL were incorporated into the language. From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Spiegel [dspiegel...@hotmail.com] Sent: Sunday, March 27, 2022 11:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I question Hi R'Shmuel AMV"SH, Like ALGOL and Pascal? Regards, David On 2022-03-27 22:52, Seymour J Metz wrote: Personally, I wish that IBM had chosen ":=" for assignment. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
On 2022-03-28 19:07, Seymour J Metz wrote: True, but it's convenient to be able to write things like "foo := sine(bar := baz);". Nonsense. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
On 2022-03-28 15:58, Jay Maynard wrote: Not me. Assignment is a much more common operation than comparison. It should be the shorter token. Agreed. '=' has been used for for assignment for 65 years. On Sun, Mar 27, 2022 at 9:52 PM Seymour J Metz wrote: Personally, I wish that IBM had chosen ":=" for assignment. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
On 2022-03-28 13:52, Seymour J Metz wrote: Personally, I wish that IBM had chosen ":=" for assignment. You've forgotten that the basis for PL/I was an improved FORTRAN, which used "=" Anyway, you can define your own assignment operator, e.g. 'assigned_from', and use the preprocessor. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
On 2022-03-28 02:45, Rupert Reynolds wrote: Related: how does LE handle strings with embedded troublesome bytes such as x'00'? And is it different between PL/I and C? Conventional strings in PL/I can contain any character. VARYINGZ strings are terminated with a character X'00'. I am reading the PL/I Programming Guide, Read the Language Specification, and check out VARYING and VARYING. but it takes but I'm hoping there is an easy off-the-cuff answer. Most of my PL/I experience was before LE, you see. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
Oops, a typo. The PL/I Optimising and checkout compilers were available from 1970. --- 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 question
From: "Bob Bridges" Sent: Saturday, March 26, 2022 12:32 PM License fee? I always assumed PL/I sort of came with the OS. It did come with the OS, from the beginning. I didn't think it'd be any extra --- 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 question
From: "CM Poncelet" <03e99a92061c-dmarc-requ...@listserv.ua.edu> Newsgroups: bit.listserv.ibm-main Sent: Saturday, March 26, 2022 11:58 AM AFAIK The reason PL/I was not 'more popular' was its high license fee. There was an alternatve available, namely, PL/C. Meanwhile, I've known people use even COBOL to write/maintain system code. As for me, I wrote all system code in assembler - bar adhoc stuff, as in to be executed once only (e.g. to convert CICS DFHCSD [?] RDO-defined LU2 connections and sessions to their equivalent assembler DFHTCT entries and macros,) which I then wrote in PL/I to save time. Not sure about PL/I being considered "too slow": it *could* be compiled with the 'optimize' [or similar] option, in the 1980's. Well, from 1980 there were available the PL/I checkout and Optimising compilers. The Optimising compiler had the REORDER option that permitted a wider range of optimisations that without the option specified. Even before that, PL/I (F) had an optimising option. Of course, PL/I (F) could be used beyond 1980. It's quite possible that some users and organisations were not aware of the REORDER option. The classic case was that of Tucker, who, in his book comparing run times of languages, failed to use the REORDER option. --- 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: Using SORT to add quotes around CHAR fields? (Listserv)
The list of attributes are obviously PL/I, and that suggests that PL/I could be the means of solving the problem. On 2022-03-24 08:20, Horacio Luis Villa wrote: Hi, the last 3 columns are CHAR but you don't want them quoted? Don't know how to do it using SORT. I'd do it with Rexx. De: IBM Mainframe Discussion List en nombre de Don Johnson <02ee771a0785-dmarc-requ...@listserv.ua.edu> Enviado: miércoles, 23 de marzo de 2022 17:46 Para: IBM-MAIN@LISTSERV.UA.EDU Asunto: [EXTERNAL] Using SORT to add quotes around CHAR fields? (Listserv) This is a post now to the listserv, instead of the Google group. Sorry for the duplication! Hi, I have a comma-delimited extract from a file that has numeric and character fields, and I would like to turn it into a true CSV file by making the character fields quoted. I have a 2-line header (column names, and column types) which indicates which are CHAR fields, but cannot figure out how to capture the information from the header to apply to the actual data lines. For example, I have this in my file: ITM_ID,DESC,SHORT_DESC,U_M,UNIT_PRICE,ON_HAND,COMMIT,INV_HOLD,DISC_QTY,DISC_PCT,B_O_QTY,ON_ORD,ACT_YR,ACT_MO,ACT_DAY CHAR(10) N.N.,CHAR(30) NOT NULL,CHAR(8) N.N.,CHAR(4) N.N.,DEC(7,2) N.N.,DEC(7,0) N.N.,DEC(7,0) N.N.,CHAR(1) N.N.,DEC(7,0) N.N.,DEC(3,1) N.N.,DEC(7,0) N.N.,DEC(7,0) N.N.,CHAR(2) N.N.,CHAR(2) N.N.,CHAR(2) N.N. A1,CARPETED RUBBER MATS-FRONT-RED,FLOORMAT,PAIR,22.99,135,205,Y,5000,1.5,0,0,87,02,02 A10001,CARPETED RUBBER MATS-REAR(RED),FLOORMAT,PAIR,12.99,277,14,N,250,1.5,0,0,86,02,20 A10002,PERSONALIZED VINYL MATS(BEIGE),FLOORMAT,PAIR,19.99,296,7,N,250,1.5,0,0,87,02,03 A10003,4-PIECE CARPET MAT SET (BLUE),MAT SET,SET,19.99,275,2,N,250,1.5,0,0,87,02,03 A10004,SPLASH GUARDS-ALUMINUM,SPLSHGRD,PAIR,8.99,523,55,N,500,1.5,0,0,87,02,03 A10005,SPLASH GUARDS-VINYL,SPLSHGRD,PAIR,8.99,550,25,N,500,1.5,0,0,87,02,03 A10006,MONOGRAMMED SPLASH GUARDS,SPLSHGRD,PAIR,11.99,300,0,N,250,1.5,0,0,86,02,20 and want the output to look like this: "A1","CARPETED RUBBER MATS-FRONT-RED","FLOORMAT","PAIR",22.99,135,205,"Y",5000,1.5,0,0,87,02,02 "A10001","CARPETED RUBBER MATS-REAR(RED)","FLOORMAT","PAIR",12.99,277,14,"N",250,1.5,0,0,86,02,20 "A10002","PERSONALIZED VINYL MATS(BEIGE)","FLOORMAT","PAIR",19.99,296,7,"N",250,1.5,0,0,87,02,03 "A10003","4-PIECE CARPET MAT SET (BLUE)","MAT SET","SET",19.99,275,2,"N",250,1.5,0,0,87,02,03 "A10004","SPLASH GUARDS-ALUMINUM","SPLSHGRD","PAIR",8.99,523,55,"N",500,1.5,0,0,87,02,03 "A10005","SPLASH GUARDS-VINYL","SPLSHGRD","PAIR",8.99,550,25,"N",500,1.5,0,0,87,02,03 "A10006","MONOGRAMMED SPLASH GUARDS","SPLSHGRD","PAIR",11.99,300,0,"N",250,1.5,0,0,86,02,20 Is there a way to see which column type contains CHAR( -- each of the types is column separated -- and then be able to apply quotes to that particular output field? I am not sure about this, but hope there is an answer here. Thank you for your help! Don Johnson Sr. Principal Support Engineer | MSD - Datacom product family Broadcom Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Word formattnig
On 2022-03-22 11:42, Paul Gilmartin wrote: On Tue, 22 Mar 2022 11:06:05 +1100, Robin Vowels wrote: Notepad has a problem with large files. It loads only the first part of a large file. How large? No one should ever need more than 640K. Rubbish. On 2022-03-22 10:53, Bob Bridges wrote: I ... But whenever I start up a new PC, one of the things I do early is teach it to open .rtf documents in WordPad. My experience, perhaps outdated: o Notepad doesn't understand UNIX linebreaks. It opens UNIX files appearing like stairs. o WordPad opens UNIX files OK, but it only Saves with DOS linebreaks. o Notepad++ opens either format and Saves by default in the input format. Many Windows editors create files with incomplete last line. Sometimes they append a SUB character. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Word formattnig
Notepad has a problem with large files. It loads only the first part of a large file. On 2022-03-22 10:53, Bob Bridges wrote: I agree. I get the impression that most Windows users ignore it entirely, and I know I have coworkers who use MS Word for pretty much all their note-taking. I use Notepad for basic notes, and WordPad if I need fonts, italics and bullet points. I doubt my victims notice the difference, since WordPad saves documents in .rtf and most folks open .rtf docs in Word. But whenever I start up a new PC, one of the things I do early is teach it to open .rtf documents in WordPad. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Monday, March 21, 2022 18:35 Notepad is underrated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
You need to look at FETCH and RELEASE PL/I statements.
Procedures not already in main storage are loaded from the disk.
►► FETCH ▼
,
entry-constant
SET ( ptr-ref ) TITLE ( char-expr )
►
► ; ►◄
Dynamic loading of an external procedure
entry-constant
Specifies the name by which the procedure to be fetched is known to the
operating system. Details of the linking considerations for fetchable procedures
are given in the Programming Guide.
The entry-constant must be the same as the one used in the corresponding
CALL statement, CALL option, or function reference.
SET
Specifies a pointer reference (ptr-ref) that will be set to the address of the
entry
point of the loaded module. This option can be used to load tables
(non-executable load modules). It can also be used for entries that are fetched
and whose addresses need to be passed to non-PL/I procedures.
If the load module is later released by the RELEASE statement, and the load
module is accessed (through the pointer), unpredictable results can occur.
TITLE
For TITLE, char-expr is any character expression or an expression that can be
converted to a character expression. If TITLE is specified, the load module
name specified is searched for and loaded. If it is not specified, the load
module name used is the environment name specified in the EXTERNAL
attribute for the variable (if present) or the entry constant name itself.
See the following example:
dcl A entry;
dcl B entry ext(’C’);
dcl T char(20) varying;
T = ’Y’;
fetch A title(’X’); /* X is loaded */
fetch A; /* A is loaded */
fetch B title(’Y’); /* Y is loaded */
fetch B; /* C is loaded */
fetch B title(T); /* Y is loaded */
For more detailed information about title strings, refer to the Programming
Guide.
"Phil Smith III" wrote in message
news:006f01d83d71$24409280$6cc1b780$@akphs.com...
I have a function that can be statically or dynamically linked. Currently
the function definition in an include file is [something like]:
Declare SOMEFN External('SOMEFN') Entry(
Char(*) byaddr,
)
returns( byvalue Fixed Bin(31) )
options ( nodescriptor, linkage(system) );
User wants to link dynamically, says this doesn't work. It appears I could
add FETCHABLE to the OPTIONS and then it would be dynamic, but reading also
suggests (without AFAICT making it clear) that then it can ONLY be linked
dynamically. Do I need two include files, one for dynamic link and one for
static? Or is there some more elegant way?
Ironically, PL/I was my first official programming language*, almost 47
years ago when I sat in on my dad's class at University of Waterloo the
summer after 8th grade, but it's been a minute! Plus that was on a Xerox
530**, which might not have had the same linkage editor rules as z/OS. I'd
ask him but he died in 2006.
---
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: Another old mainframe comparison
On 2021-12-23 01:59, Bob Bridges wrote: I'm enjoying the article so far, and I'm sure contributors will chime in who are far more knowledgeable than I. But the first thing I notice is that he spends some time estimating how inferior the early 7090 was to a modern laptop in terms of clock speed, RAM, and tape-driven I/O, and concludes "So now the 7090 looks to have run at about a quadrillionth (10-15) the speed of your 2021 laptop." The first thing that leaps out at me is that he appears to be multiplying the three comparative numbers to come up with a quadrillion. But that isn't the proper way to compare speeds, is it? Surely the proper comparison is only the slowest of the three. Not to mention the silly typographical error of writing 10 to the 15th as "10-15". I use "10e15", myself, um, 10e15 is 10 x 10**15, or 1e16, though I suppose in a magazine with decent capabilities a superscript might look more professional. This article, though, isn't comparing modern PCs to modern mainframes, so no need to wax indignant. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another old mainframe comparison
Burroughs had the B5000 in 1961. At 100,000 instructions per second, the 7090 wasn't all that fast. Pilot ACE, in 1951, could execute 15,000 instructions per second. On 2021-12-22 17:26, Tom Brennan wrote: I don't know what's going on with the comparisons lately, but here's a fun one. Paging the fact checkers... https://spectrum.ieee.org/ibm-mainframe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Replacement for TM instruction
Murphy's Law is "If anything can go wrong, it will." Roberts's Law is: "Even if it can't go wrong, it will." (will the real Murphy please stand up?) On 2021-12-11 08:04, Charles Mills wrote: https://en.wikipedia.org/wiki/Muphry%27s_law Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Replacement for TM instruction
- Original Message - From: "Seymour J Metz" Newsgroups: bit.listserv.ibm-main Sent: Saturday, December 11, 2021 12:56 AM For a test of a single bit you can do a logical and on a copy of the byte or use NRK. For testing multiple bits you can execute a TM. You mean, EXexute a TM. --- 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: Replacement for TM instruction
On 2021-12-10 10:02, Joe Monk wrote: Hi, Would this work? Definitely not. It's the same problem as before. TM requires the mask as part of its instruction. As others have suggested, the B operand can be supplied by using EX. An alternative would be to use NC to test for the single bit. MVI B,X'08' MVI A,X'1C' TMA,B BOLABEL A DS X B DS X Joe On Thu, Dec 9, 2021 at 3:11 PM Ituriel do Neto < 03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote: Hi all, I would like advice because i have a situation where i need to check a bit of a storage area, usinganother storage area as a pattern and not an immediate. I have something like this : A DCX'1C'B DCX'08' TMA,x'08' JOX But instead of using x'08', i need to use the variable B in the comparison, because the content of B may change.So, i would need something like this: TM A,B How can i do that ? Thanks in advance. Best Regards Ituriel do Nascimento Neto z/OS System Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VisualAge PL/I question
IBM OS Optimising Compiler is a product of the 1970s. VisualAge PL/I is a product of the 1990s or post 2000. On 2021-10-30 09:41, Charles Mills wrote: Is VisualAgeR PL/I V2 the same product as 5668-910 IBM OS PL/I Optimizing Compiler V2? Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Variable length records for SYSIN data sets
We used to use RECFM=V in the 1960s with SYSIN for PL/I source programs on paper tape. On 2021-10-29 11:56, Paul Gilmartin wrote: On Thu, 28 Oct 2021 22:49:49 +, Seymour J Metz wrote: What happens with //INFILE DD DISP=SHR,DSN=MY.VB.FILE // DD *,DCB=(RECFM=V,LRECL=204) and have you reported it as a bug, citing the text that you quoted? I haven't RTFM today, but I believe it has long been a documented restriction. I've readily used: o An Edit macro which does EXECIO to a DDNAME allocated with RECFM=VB o FTP with "QUOTE SITE FILE=JES"; "QUOTE SITE JESRECFM=V" o IEBGENER witn //SYSUT2 DD SYSOUT=(B,INITRDR) o Etc. Not a bug; WAD. Merits an RFE. From:Frank Swarbrick Sent: Thursday, October 28, 2021 5:11 PM I have a goal to concatenate a data set of variable length records (RECFM=VB,LRECL=204) with an instream data set of fixed length characters. My though was to add RECFM=V to my instream DD, i.e.: //INFILE DD DISP=SHR,DSN=MY.VB.FILE // DD *,RECFM=V,LRECL=204 The RECFM is rejected as being conflicting with a SYSIN dataset: IEFC009I KEYWORD RECFM IS MUTUALLY EXCLUSIVE WITH KEYWORD SYSIN ON THE DD STATEMENT And yet the following section of the manual, "SYSIN data set" has discussion of SYSIN data sets where "the record format is variable": https://www.ibm.com/docs/en/zos/2.5.0?topic=ssds-sysin-data-set But how do I actually make the SYSIN dataset variable length? I do realize there are probably other options to accomplish my task, but this is bugging me. RFE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I vs. JCL
- Original Message - From: "Charles Mills" To: Sent: Tuesday, September 28, 2021 11:19 AM column 1 is reserved for carriage control. That seems to conflate source code with SYSPRINT. It does seem to, but in fact PL/I supports source listing formatting using ANSI carriage control. "The MARGINS option specifies which part of each compiler input record contains PL/I statements, and the position of the ANS control character that formats the listing, ..." -- PL/I P/G At some stage, the preprocessor commands %PAGE and %SKIP were introduced to improve source listings. Maybe they were always there, but I have a vague recollection that at some stage it was not necessary to have the preprocessir activated to make them work. --- 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 vs. JCL
From: "Joe Monk" To: Sent: Tuesday, September 28, 2021 8:36 AM PL/I is free format. The default is 2 - 72, IBM's catalogue procedure was set up for columns 2 to 72. Sites could change that -- as ours did -- to read columns 1 to 80. but there is a compiler option to change that (SORMGIN). Joe --- 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 vs. JCL
- Original Message - From: "Mike Schwab" To: Sent: Tuesday, September 28, 2021 8:12 AM PL/I uses column one for a carriage control while JCL requires a / in column one, so this was never a problem PL/I does not use card column 1 for carriage control. That was an option that a programmer could use, but IIRC, that option was not available with the initial release. --- 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 vs. JCL
- Original Message - From: "Phil Smith III" To: Sent: Tuesday, September 28, 2021 8:08 AM A friend writes: In a conversation elsewhere I mentioned the oops between JCL using /* as end of dataset and PL/I using /* */ for comment brackets - meaning that PL/I had to start in column 2 to prevent a comment from being interpreted as JCL. PL/I source program could start between card columns 1 and 80, as we did on our site. IBM had set up some catalogue procedures to use only card columns 2 to 72. We changed that. All the programmer needed to do was to avoid starting a comment in card column 1. As for the PL/I SSP, we converted the card images from 48-character set to the 64-character set. At the same time, we removed the card numbers in card columns 73 to 80, and inserted card numbers within a comment starting in card column 73 and finishing at card column 80. Oopsie. Does anyone remember which came first? There was some rumor that I no longer remember that one group didn't like the other group so some of this done on purpose. I've never heard this, which proves nothing much, but leads me to ask: anyone else here ever heard it? I'd've guessed JCL came first, since PL/I was still in development as of December 1964 per the Wikipedia page. But this is the right place to get some answers (or at least opinions)! --- 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: Coding for the future
On 2021-06-17 19:15, Rob Scott wrote: When it comes time to change the length of a token, or locate usage occurrences, I would much prefer to hunt for Token_Len rather than determine usage context for some numeric. I would also probably feel more confident about the results. Absolutely - let ASMA90 do the work. Magic numbers are a real maintenance head-ache. If there is a defined “field” and the number reflects its length, then I would use something like “LHI Rx,L’Token”. I feel that this helps with the self-commenting coding style. A minor nit, but I prefer something like “LHI Rx,value” to “LA Rx,value” as the implication of “LA” is that you are dealing with an address rather than a constant numerical value. Before LHI, you could write your own macro, to give you LA 4,7 and at the same time include a check on the magnitude of the constant. Also, it could deal with signed constants. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blocked SYSIN/SYSOUT
On 2020-11-20 12:32, Paul Gilmartin wrote: jn: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.hasc300/has2z1_Use_of_unblocked_records_for_SYSIN_and_SYSOUT_data_sets.htm You should not block SYSIN and SYSOUT data sets because the SAM (sequential access method) compatibility interface will increase overhead by unnecessarily deblocking and blocking data sets. That seems strange. Who said that? In what context? In the old days, it was important to block SYSOUT. Unblocked input and output contributed to disc threshing, which resulted in reduced performance of the disc system as well as slowing down output speed. I didn't know that. Should I have RTFM? Is SDB aware of that? If BSAM, is this offset by more calls to WRITE/READ? BLKSIZE is incompatible with DD */DATA, perhaps because the programmer is expected to use F/V rather than FB/VB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PC market (was IBM splitting into two companies)
On 2020-10-12 00:57, Bill Johnson wrote: So market cap is now the determining factor for the best companies? Here’s the 1980 list of market cap leaders. Had IBM not been forced out of the PC market, I’d bet IBM would still be at or near the top, and MSFT wouldn’t be. "Forced out". I think not. IBM gave up that market. 1980: 1. IBM 2. AT 3. Exxon 4. Standard Oil of Indiana 5. Schlumberger 6. Shell Oil 7. Mobil 8. Standard Oil of California 9. Atlantic Richfield 10. GE -- 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
- 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: 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 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 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 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 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: 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: PL/I integers
On 2020-09-08 00:15, Seymour J Metz wrote: Did you read what I wrote? The code you wrote has nothing to do with the expression I gave. Oops, a typo. The PUT should have read PUT ( (I/J)*6 ); to produce 6. How about DECLARE (I, J) FIXED DECIMAL (15); I = 4; J = 3; PUT ((I/J*J)); That's nothing like what you wrote. You wrote (4/3)*6 From: IBM Mainframe Discussion List on behalf of Robin Vowels Sent: Monday, September 7, 2020 5:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I integers (was: Constant Identifiers) On 2020-09-07 16:13, Seymour J Metz wrote: PL/I has never had integers. You are still wrong. Recently you have made numerous erroneous claims about PL/I. 4 is an integer in PL/I. 3 is an integer in PL/I. The arithmetic rules for scaled fixed point are different from those for integers. Scaled, with a scale factor other than zero and with a fractional part, yes, because they are not then integers. However, with scale factor of zero, they are integers. In integer arithmetic, (4/3)*6 is 6 That's not the result you get in PL/I. With the following declarations, you'll get the same result in PL/I, namely, 6: DECLARE (I, J) FIXED DECIMAL (15); I = 4; J = 3; PUT (I/J); will print 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
You think that I am not looking at IBM's PL/I LRM? On 2020-09-07 23:25, Joe Monk wrote: The answer is here: https://www.ibm.com/support/knowledgecenter/SSY2V3_5.2.0/com.ibm.ent.pl1.zos.doc/lr/resarithoprt.html Joe -- 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 are looking at the wrong part of the table. This discussion is about DECIMAL operands. what I wrote is correct for such. See Table 15 top entry, for ANS rules for division; Table 16 top entry, for IBM rules. On 2020-09-07 22:19, Joe Monk wrote: Actually it does... Under the IBM suboption: - Nonzero scale factors are permitted in FIXED BIN declarations. - If the result of any precision-handling built-in function (ADD, BINARY, and so on) has FIXED BIN attributes, the specified or implied scale factor can be nonzero. Under the ANS suboption: - Nonzero scale factors are not permitted in FIXED BIN declares. - If the result of any precision-handling built-in function (ADD, BINARY, and so on) has FIXED BIN attributes, the specified or implied scale factor must be zero. https://www.ibm.com/support/knowledgecenter/SSZHNR_2.0.0/com.ibm.ent.pl1.zos.doc/pg/rules.html Joe On Mon, Sep 7, 2020 at 12:23 AM Robin Vowels wrote: On 2020-09-07 13:05, Joe Monk wrote: > "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. It doesn't depend on whether IBM rules or ANS rules are in force. What I said it correct for IBM rules also. The result is always an integer. See Table 16. When the operands have maximum precision, the result is integer. The formulas for precision and scale factor are exactly the same. > If its RULES(ANS) and the operands are unscaled, then it > will be integer division. > > 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) -- 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 (was: Constant Identifiers)
On 2020-09-07 16:13, Seymour J Metz wrote: PL/I has never had integers. You are still wrong. Recently you have made numerous erroneous claims about PL/I. 4 is an integer in PL/I. 3 is an integer in PL/I. The arithmetic rules for scaled fixed point are different from those for integers. Scaled, with a scale factor other than zero and with a fractional part, yes, because they are not then integers. However, with scale factor of zero, they are integers. In integer arithmetic, (4/3)*6 is 6 That's not the result you get in PL/I. With the following declarations, you'll get the same result in PL/I, namely, 6: DECLARE (I, J) FIXED DECIMAL (15); I = 4; J = 3; PUT (I/J); will print 6 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" To: 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 result is FIXED DECIMAL, not binary. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I declarations (was: Constant Identifiers)
On 2020-09-07 15:15, Seymour J Metz wrote: No, FIXED BIN(15,0) is not an integer, and the precision rules can be very annoying to those with a Fortran mindset. If it looks like a duck and quacks like a duck, it probably is a duck. An integer is a whole number. FIXED BINARY (15) and FIXED BINARY(15,0) are both attributes describing a whole number, that is, an integer. From: IBM Mainframe Discussion List on behalf of Joe Monk Sent: Sunday, September 6, 2020 7:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Constant Identifiers "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)... Joe On Sun, Sep 6, 2020 at 2:33 PM Seymour J Metz wrote: PL/I doesn't have integers. The ratiio 4/3 is FIXED BIN, with some number of bits after the binary point. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 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
Re: PL/I division (was: Constant Identifiers)
On 2020-09-07 14:56, Seymour J Metz wrote:
No: see
https://www.ibm.com/support/knowledgecenter/SSY2V3_5.3.0
/lr/resarithoprt.html#resarithoprt__fig16,
Tables 3 and 4. For 4/3, the scale factor is 1, not 0.
4 is FIXED DECIMAL (1,0).
3 IS fixed decimal (1,0).
4/3 is fixed decimal (15,14).*
See Table 16.
It's been that way since 1965.
* given that the maximum precision is 15.
From: IBM Mainframe Discussion List on
behalf of Robin Vowels
Sent: Sunday, September 6, 2020 8:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Constant Identifiers
- Original Message -
From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, September 06, 2020 11:07 PM
On Sun, 6 Sep 2020 17:25:45 +1000, Robin Vowels wrote:
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'?
The type and precision of constants are as written.
Thus, both 4 and 3 are FIXED DECIMAL (1).
Does PL/I entirely lack an integer divide?
PL/I can do integer division. When the operands are of
maximum precision, anm integer result is produced.
Thus, for
DECLARE (I, J) FIXED BINARY (31);
then
I / J;
produces an integer result of precision (31,0).
Similarly of I and J were defined with maximum precision.
Also, as Seymour Metz points out, the DIVIDE built-in function may
be used to produce an integer result.
Or, you can go ahead with the division, and the result will be
truncated
to an integer by assigning to an integer variable. However, that
wastes time with unnecessary computation.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Constant Identifiers
On 2020-09-07 13:05, Joe Monk wrote: "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. It doesn't depend on whether IBM rules or ANS rules are in force. What I said it correct for IBM rules also. The result is always an integer. See Table 16. When the operands have maximum precision, the result is integer. The formulas for precision and scale factor are exactly the same. If its RULES(ANS) and the operands are unscaled, then it will be integer division. 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) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Constant Identifiers
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) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Constant Identifiers
From: "Bob Bridges" Sent: Monday, September 07, 2020 8:29 AM To tell you the truth, I haven't written for a compiler in long enough that I don't have any idea which ones do what. I wouldn't trust REXX, CLIST or VBA to do it; I try to assume the worst, and make such things explicit. Actually I might not trust a compiler to do it, either, even if I knew that you're right. I'm just not very trusting about such things. (And it's not ~very~ obfuscatory. In real life I'd include a comment, something like this: SphereVolConst=4/3*3.14159E0 /* for calculating the volume of a sphere inside the loop */ Why do that, when the compiler will probably do it for you, or, if it doesn't, it will evaluate the constant part at compilation time -- which is effectively the same thing. That looks like a lot of documentation, to some programmers. But the older I get, the more comments I write into even fairly simple programs.) --- 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: Constant Identifiers
From: "Robert Prins"
Sent: Monday, September 07, 2020 3:42 AM
On 2020-09-06 13:07, Paul Gilmartin wrote:
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?
No,
Yes it does.
In an earlier letter, I pointed out that when both integer operands
for division are of the same type and are of maximum precision
PL/I produces an integer result.
if the receiving variable is an integer without fractional part, PL/I truncates.
Yes, it can do that too.
---
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: Constant Identifiers
- Original Message -
From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, September 06, 2020 11:07 PM
On Sun, 6 Sep 2020 17:25:45 +1000, Robin Vowels wrote:
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'?
The type and precision of constants are as written.
Thus, both 4 and 3 are FIXED DECIMAL (1).
Does PL/I entirely lack an integer divide?
PL/I can do integer division. When the operands are of
maximum precision, anm integer result is produced.
Thus, for
DECLARE (I, J) FIXED BINARY (31);
then
I / J;
produces an integer result of precision (31,0).
Similarly of I and J were defined with maximum precision.
Also, as Seymour Metz points out, the DIVIDE built-in function may
be used to produce an integer result.
Or, you can go ahead with the division, and the result will be truncated
to an integer by assigning to an integer variable. However, that
wastes time with unnecessary computation.
---
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: Constant Identifiers
From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> To: 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
Re: Constant Identifiers
- Original Message - From: "Seymour J Metz" To: 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
Re: Constant Identifiers
"Seymour J Metz" wrote in message news:bl0pr05mb5156591ed17d7bddfaee695299...@bl0pr05mb5156.namprd05.prod.outlook.com... The default type for 3 and 4 is FIXED BINARY. No it's not. Constants have the type and precision of the constant. Thus, 3 and 4 are both FIXED DECIMAL (1) > PL/I does not have an integer type, Yes it does,. DECLARE X FIXED BINARY; defines an integer variable X. 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. --- 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: Constant Identifiers
On 2020-09-06 13:33, Paul Gilmartin wrote: 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. No it's not. 4/3 yields 1.33.. to 15 digits in PL/I. You're thinking of FORTRAN. However, if I'm interested in efficiency, I'd prefer volume = 4 * 3.14159E0 / 3 * radius**3 ... (and correct.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Constant Identifiers
That's obfuscation. If it's in a loop, I'd expect the compiler to move the constant part outside of the loop, or to evaluate the constant part at compilation time. In any case, the more efficient form eliminates the division 4/3, avoiding the avaluation in fixed-point form (and the conversion to floating-point). - Original Message - From: "Bob Bridges" Newsgroups: bit.listserv.ibm-main To: Sent: Sunday, September 06, 2020 6:18 AM Subject: Re: Constant Identifiers When you care about efficiency, I'd think this would be better: const=4/3*3.14159E0 /* in the initialization */ volume=const*radius**3 /* inside the loop */ --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Things may come to those who wait, but only those things left behind by those who hustle. -attributed (probably falsely) to Abraham Lincoln, lawyer */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robin Vowels Sent: Friday, September 4, 2020 18:14 As for writing formulas, I prefer to follow a well-known formula, thus: volume = 4/3 * 3.14159 * radius**3 However, if I'm interested in efficiency, I'd prefer volume = 4 * 3.14159E0 / 3 * radius**3 --- 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)
On 2020-09-06 11:50, Seymour J Metz wrote: Eschew obfuscation. Either just use 0 and one, or write false=0;true=1. Similarly, for PL/I either just use '0'b and '1'b or write false='0'b;true='1'b;. VALUE is a good alternative also. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Constant Identifiers
"Seymour J Metz" wrote in message news:bl0pr05mb5156e311e88735a8afbef5ca99...@bl0pr05mb5156.namprd05.prod.outlook.com... If you don't care about maintainable code than should is to strong. If you care about maintainable code then should is too weak. The purpose of a LRM is to tell you what facilities are available. Not to impose programming conventions or rules -- that's the prerogative of the installation. --- 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: Constant Identifiers
On 2020-09-05 05:03, Paul Gilmartin wrote: On Fri, 4 Sep 2020 17:10:36 +, Farley, Peter x23353 wrote: Sounds to me like the documentation writer was a bit confused. Looks to me like it should read instead: If th nnumber 3.1416 is used in more than one place in the program, then you *should* declare it as a named constant. No. "Even "should" is too strong. As I wrote earlier. "may" should have been used. If it requires specific data or precision attributes at different places in the program, then you *must* declare it as a named constant. Yes. The first sentence discusses style and belongs in a Programmers Guide. It should just be removed from a Language Reference. I haven't Enterprise PL/I. Can anyone supply a compiled counterexample, perhaps: area = (radius**2) * 3.1416; volume = (radius**3) * 4/3 * 3.1416; ...? I'll submit an RCF. As for writing formulas, I prefer to follow a well-known formula, thus: volume = 4/3 * 3.14159 * radius**3 However, if I'm interested in efficiency, I'd prefer volume = 4 * 3.14159E0 / 3 * radius**3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Constant Identifiers
On 2020-09-05 01:43, Paul Gilmartin wrote: I'm a PL/I novice, or less. A recent thread here moved me to browse the Ref., where I read that any constant used more than once must be declared and the identifier used instead. Sorta tyrannical enforcement of coding conventions. OK. I agree that 6.62607015e−34 shouldn't be hard-coded more than once. But SQRT( X**TWO + Y**TWO )? Ugh!- It doesn't mean what it says. They should have used the word "may" instead of "must". It's simply a matter of convenience. You can write a constant how you like, and more than once. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
