Re: z/PDT
If you are doing any coding to learn, that is going to be OK. If you happen to code anything that is useful to run on your employer's mainframe, it probably won't be detected since it would fall under site written software. If you try to sell to any non-employer company they are probably going to check if you are an IBM partner or their recognized list of mainframe vendors. On Tue, Mar 29, 2022 at 4:49 AM Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > > On 3/27/22 10:11 PM, Brian Westerman wrote: > > I think you could probably learn "how" to make your product on the LE > > edition and if things start working out for you and you think you might > > have a viable product, you could then switch to the personal edition. > > That seems like you could potentially end up in some uncharted > territory. Especially if you copied any code from the LE to the non-LE > edition. > > Maybe IBM would allow you to retroactively upgrade from the LE license > to a non-LE license to work around the licensing issue. > > The what is learning vs what is developing an earlier version seems to > be a murky thing to me. > > > > -- > Grant. . . . > unix || die > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/PDT
On 3/27/22 10:11 PM, Brian Westerman wrote: I think you could probably learn "how" to make your product on the LE edition and if things start working out for you and you think you might have a viable product, you could then switch to the personal edition. That seems like you could potentially end up in some uncharted territory. Especially if you copied any code from the LE to the non-LE edition. Maybe IBM would allow you to retroactively upgrade from the LE license to a non-LE license to work around the licensing issue. The what is learning vs what is developing an earlier version seems to be a murky thing to me. -- Grant. . . . unix || die -- 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
You claimed that a lot of things came from FORTRAN that don'r look remotely like FORTRAN syntax, 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. Some of what you claimed came from FORTRAN doesn't even exist in PL/I. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 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:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: IDCAMS ALIAS vs a symbolic link?
On Mon, 28 Mar 2022 22:39:12 +, Pommier, Rex wrote: > >... Just for fun I defined a symbolic called and IPLed my sandbox > resulting in (in part) this: > >IEA007I STATIC SYSTEM SYMBOL VALUES 045 > = "" > >I then defined a new SYM alias: > > DEF ALIAS(NAME(SYS1.REX) SYM(RRP.)) >IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 > Is the substituted value required to be (exactly one?) entire qualifier? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: IDCAMS ALIAS vs a symbolic link?
Hi Gil, You asked why SYMBOLICRELATE doesn't work. At my site at least, SYM doesn't work because it drops the alias entry into the same catalog as the base entry, regardless of what catalog the HLQ should be putting the alias into. Just for fun I defined a symbolic called and IPLed my sandbox resulting in (in part) this: IEA007I STATIC SYSTEM SYMBOL VALUES 045 = "" I then defined a new SYM alias: DEF ALIAS(NAME(SYS1.REX) SYM(RRP.)) IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 My SYS1 datasets are normally defined in the master catalog - I don't use multi-level aliasing. I then tried to find/use SYS1.REX using standard catalog searching and got "not found". I dumped the user catalog that has RRP.JCL in it and I found SYS1.REX in the same catalog. Here are the relevant entries: LISTC CAT(CATALOG.USERCAT.TSO1) ALL NONVSAM --- RRP.JCL VOLUMES VOLSERSFG001 DEVTYPE--X'3010200F' ASSOCIATIONS(NULL) ATTRIBUTES ALIAS - SYS1.REX HISTORY RELEASE2 CREATION2022.087 ASSOCIATIONS SYMBOLIC-RRP. RESOLVED-RRP.JCL So it looks like we're still stuck with the SYM alias being in the same catalog as the base entry. I did not try using the SYMBOL as the HLQ of the dataset name. Perhaps that would resolve correctly but the way I read the "managing catalogs" manual, there was no such restriction. That is, of course, unless I'm using SYM completely wrong which is possible, because I've never used it before playing with it today. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Monday, March 28, 2022 1:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: IDCAMS ALIAS vs a symbolic link? On Mon, 28 Mar 2022 15:27:22 +, Seymour J Metz wrote: >He's looking for an alias without the restriction of being in the same >catalog. > What's wrong with SYMBOLICRELATE? >That would be useful for people who haven't set things up to exploit >SYMBOLICRELATE, but I doubt that IBM will be willing to do it. > The simple RFE would be that the restriction that the related name contain an "&" be removed. It strikes me as an manifestation of a Catalog mindset that z/OS supports "$" symbol expansion in symlinks. Solaris met a similar need with symbols in mount maps. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF30_USERKEYCSAUSAGE Question
Is this customer running back-level software? Some very old Omegamon versions had user key CSA from my memory, and that could explain the otherwise strange mix of address spaces you are reporting. Lots of other old software also used user key CSA (hence why IBM provided the RUCSA feature as a solution for those cases). On Tue, Mar 29, 2022 at 7:51 AM shivang sharma wrote: > While evaluating SMF 30 data for one customer found few address spaces > being reported with the SMF30_USERKEYCSAUSAGE bit on. Below are few > examples : > > 1)INIT address spaces program IEFIIC (SMF30 subtype 4 step records) > 2)DB2 MSTR , IRLM , DBM1 address spaces. > 3)MSTJCL00 ad program IEEMB860.(SMF30 subtype 2,3) > > I suspect somehow these address spaces are not being accurately reported > in the SMF 30 or I am missing something. > > Anybody who can help in shedding some light on why these observations are > being reported with the SMF30_USERKEYCSAUSAGE bit on. > > Thanks > Shivang > > -- > 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
SMF30_USERKEYCSAUSAGE Question
While evaluating SMF 30 data for one customer found few address spaces being reported with the SMF30_USERKEYCSAUSAGE bit on. Below are few examples : 1)INIT address spaces program IEFIIC (SMF30 subtype 4 step records) 2)DB2 MSTR , IRLM , DBM1 address spaces. 3)MSTJCL00 ad program IEEMB860.(SMF30 subtype 2,3) I suspect somehow these address spaces are not being accurately reported in the SMF 30 or I am missing something. Anybody who can help in shedding some light on why these observations are being reported with the SMF30_USERKEYCSAUSAGE bit on. Thanks Shivang -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS ALIAS vs a symbolic link?
On Mon, 28 Mar 2022 15:34:41 -0400, Steve Smith wrote: >I don't know what technical reasons there are for restricting an alias to >be in the same catalog as its target, but they would certainly be much >more powerful if they weren't. It would also be nice to have symlinks that >could point at MVS datasets, and aliases that pointed at USS files. > A coalescence of MVS data sets and UNIX files was mentioned here a few months ago and affirmed by wjs on Tue, 21 Dec 2021 07:41:08 -0600. >I don't see that it could hurt to ask. > And PDSE in $PATH, and UNIX directories in STEPLIB and SYSEXEC, which works sporadicallly but is unsupported. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS ALIAS vs a symbolic link?
I don't know what technical reasons there are for restricting an alias to be in the same catalog as its target, but they would certainly be much more powerful if they weren't. It would also be nice to have symlinks that could point at MVS datasets, and aliases that pointed at USS files. I don't see that it could hurt to ask. sas On Mon, Mar 28, 2022 at 10:37 AM Rob Schramm wrote: > I wasn't actually talking about using a symbol (as in system symbol)... but > referring to the unix command create symbolic link. > ln -s [OPTIONS] FILE LINK > > and that is why I was proposing a SYMLINK. but I am not tied to the name > if it causes confusion. ALIASLINK works.. or something like it. > > I am much more interested in the underlying functionality and > creating something useful for helping sysprogs and other manage catalogs. > > Rob > > -- 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
Thanks for the hints folks suggested. It turns out that the PL/I preprocessor does make this easy, via something like: %Dcl Forn Char; %if Uppercase(Dyn) = 'YES' %then %do ; %Forn = ', fetchable'; %end; %else %do; %Forn = ''; %end; Then you just include the Forn variable in the function prototypes, where it appears as null or , fetchable. I had some problems with this because I was using a preprocessor variable named DYN and my test program was also DYN. That meant that the end dyn; statement at the end of the program became end yes;, which the compiler didnt much like. So yes, I used much longer variable names that nobody should ever trip over! While its a neat facility, I dont see any way to override it. If you think of CLIST or CMS EXEC/EXEC 2, variables were indicated by an &. Rexx variable use is more natural, but you can override it by quoting, and it doesnt interpret keywords as variables. I tried, and end 'dyn'; does NOT workPL/I doesnt like the quotes (plus you couldnt really quote every keyword and still read the program). This seem potentially nasty: if you set a variable named DECLARE, all your DECLARE statements are now something else. That feels like a huge security issue: you %include some member and hilarity ensues (PL/I injection??). Or just as a joke, back when we printed listings) defining SKIP as PAGE and watching someone use a box of greenline for a short program... My dad once told me that hed seen a PL/I program in South America somewhere in which the language itself was Spanishthe keywords etc. So si for if (not to be confused with yes!) and más hacer for else do, etc. Im now suspecting this was done using the preprocessor. I suppose its a bit late to APAR this. (Thanks to a list-mate here whom I wont name, who did the real work on thishes welcome to out himself if desired [yes I just indicated gender]) ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS ALIAS vs a symbolic link?
On Mon, 28 Mar 2022 15:27:22 +, Seymour J Metz wrote: >He's looking for an alias without the restriction of being in the same >catalog. > What's wrong with SYMBOLICRELATE? >That would be useful for people who haven't set things up to exploit >SYMBOLICRELATE, but I doubt that IBM will be willing to do it. > The simple RFE would be that the restriction that the related name contain an "&" be removed. It strikes me as an manifestation of a Catalog mindset that z/OS supports "$" symbol expansion in symlinks. Solaris met a similar need with symbols in mount maps. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS ALIAS vs a symbolic link?
He's looking for an alias without the restriction of being in the same catalog. That would be useful for people who haven't set things up to exploit SYMBOLICRELATE, but I doubt that IBM will be willing to do it. From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Monday, March 28, 2022 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IDCAMS ALIAS vs a symbolic link? On Mon, 28 Mar 2022 10:36:42 -0400, Rob Schramm wrote: >I wasn't actually talking about using a symbol (as in system symbol)... but >referring to the unix command create symbolic link. >ln -s [OPTIONS] FILE LINK >... >I am much more interested in the underlying functionality and >creating something useful for helping sysprogs and other manage catalogs. > What, in more detail, is the function you want? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS ALIAS vs a symbolic link?
I understood exactly what you were asking for, and I explained why I expected that IBM would not be receptive to an RFE. Back in the CVOL era there was somewhat of an analogy between index levels and Unix directories, but things are different with VSAM catalog. The whole inode thing doesn't exist for classic datasets. From: IBM Mainframe Discussion List on behalf of Rob Schramm Sent: Monday, March 28, 2022 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IDCAMS ALIAS vs a symbolic link? I wasn't actually talking about using a symbol (as in system symbol)... but referring to the unix command create symbolic link. ln -s [OPTIONS] FILE LINK and that is why I was proposing a SYMLINK. but I am not tied to the name if it causes confusion. ALIASLINK works.. or something like it. I am much more interested in the underlying functionality and creating something useful for helping sysprogs and other manage catalogs. Rob On Sun, Mar 27, 2022 at 8:43 AM Seymour J Metz wrote: > I would expect IBM to tell you to use SYMBOLICRELATE. Index levels in > dsnames are not, in general, catalog names, and that makes the analogy with > Unix paths a bit sketchy. > > > -- > Shmuel (Seymour J.) Metz > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7Csmetz3%40gmu.edu%7C8f8a302678e94cf5d5a608da10c878f5%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637840750468953897%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=3pHni4EBIoTJb0HbBcIofwnFZrJKfXkSg9GKdIaleJI%3Dreserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Rob Schramm [rob.schr...@gmail.com] > Sent: Saturday, March 26, 2022 6:40 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IDCAMS ALIAS vs a symbolic link? > > All, > Has anyone considered how the current ALIAS restrictions are a bit > limiting? And that something more like a symbolic link (USS and for those > that object z/Unix) would be helpful? > > In this example we have a ISV product that has JCL far flung and we want to > change the HLQ and move it to another catalog... but put it in without > disrupting things. > > usercat1 has the old data sets - SYSUC1.some.product > usercat2 has the new data sets - SYSUC2.some.new.product > > such that SYSUC1.some.product gets renamed to SYSUC1.some.product.old and > we create a symbolic link in usercat1 actually points to the data sets in > usercat2. > > It just seems like the ALIAS system is quite limited when we consider that > a symbolic link is a bit more flexible. > > DEF SYMLINK(NAME(SYSUC1.SOME.PRODUCT) REL(SYSUC2.SOME.NEW.PRODUCT) ) > > Let me know what you think. > > Rob Schramm > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS ALIAS vs a symbolic link?
On Mon, 28 Mar 2022 10:36:42 -0400, Rob Schramm wrote: >I wasn't actually talking about using a symbol (as in system symbol)... but >referring to the unix command create symbolic link. >ln -s [OPTIONS] FILE LINK >... >I am much more interested in the underlying functionality and >creating something useful for helping sysprogs and other manage catalogs. > What, in more detail, is the function you want? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS ALIAS vs a symbolic link?
I wasn't actually talking about using a symbol (as in system symbol)... but referring to the unix command create symbolic link. ln -s [OPTIONS] FILE LINK and that is why I was proposing a SYMLINK. but I am not tied to the name if it causes confusion. ALIASLINK works.. or something like it. I am much more interested in the underlying functionality and creating something useful for helping sysprogs and other manage catalogs. Rob On Sun, Mar 27, 2022 at 8:43 AM Seymour J Metz wrote: > I would expect IBM to tell you to use SYMBOLICRELATE. Index levels in > dsnames are not, in general, catalog names, and that makes the analogy with > Unix paths a bit sketchy. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Rob Schramm [rob.schr...@gmail.com] > Sent: Saturday, March 26, 2022 6:40 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IDCAMS ALIAS vs a symbolic link? > > All, > Has anyone considered how the current ALIAS restrictions are a bit > limiting? And that something more like a symbolic link (USS and for those > that object z/Unix) would be helpful? > > In this example we have a ISV product that has JCL far flung and we want to > change the HLQ and move it to another catalog... but put it in without > disrupting things. > > usercat1 has the old data sets - SYSUC1.some.product > usercat2 has the new data sets - SYSUC2.some.new.product > > such that SYSUC1.some.product gets renamed to SYSUC1.some.product.old and > we create a symbolic link in usercat1 actually points to the data sets in > usercat2. > > It just seems like the ALIAS system is quite limited when we consider that > a symbolic link is a bit more flexible. > > DEF SYMLINK(NAME(SYSUC1.SOME.PRODUCT) REL(SYSUC2.SOME.NEW.PRODUCT) ) > > Let me know what you think. > > Rob Schramm > > -- > 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 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
Oddly enough, you listed lots of 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. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 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 -- 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
Hi Robin, You said: "... These new features were introduced in PL/I: ..." Pseudo-variables (i.e. SUBSTR, UNSPEC), Source Margins (not exactly the language itself). Regards, David On 2022-03-28 06:26, Robin Vowels wrote: 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 . -- 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
In PL/I (F) Version 5 the optimization regressed. While SUBSTR was still inline for CHAR, that was not always the case for bit strings. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 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:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fantivirusdata=04%7C01%7Csmetz3%40gmu.edu%7Cb88d6b6074004155e27008da109d6b6b%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637840565556021849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=k%2B3eL8AkSX9NWqt5pRNGrPmdQpycjdXeGbH6anEP%2BlU%3Dreserved=0 -- 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 question
Nonsense, that's only one case of a length explicitly determined at run time.. A declaration of an AUTO CHAR(foo) variable is another case. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 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:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 -- 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
No.
"I meant what I said and I said what I meant,
A SysProg is faithful, 100%."
("Horton Hears an IPL", Dr. Seus)
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
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:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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
--
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
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. Most of the language derives from Algol 60 and COBOL, and the most obvious feature from FORTRAN has gone by the wayside. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 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. > > 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 -- 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
Yes, I meant VARYINGZ. Zero termination, no interpolation, the normal doubling in literals. Block entry *is* run time. Also, exempli gratia (e.g.) means for example; had that been a complete list I would have written id est (i.e.). -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 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. --- This email has been checked for viruses by Avast antivirus software. https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fantivirusdata=04%7C01%7Csmetz3%40gmu.edu%7Ca43301e2286b4a159f4508da1099efc5%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637840550603608176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=kXy%2B1RafUdg7GOvkg6K7lbgiWmQnf1%2FartCjlfIEa5k%3Dreserved=0 -- 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 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
Exaclly, especially since Algol 60 was one of the three languages folded into PL/I. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 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. > > > -- > Shmuel (Seymour J.) Metz > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7Csmetz3%40gmu.edu%7Ce9e248bf75944683e28408da106c86f3%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637840355848465546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=T0nyZXeRmQFRih61UBfLB4%2B%2FnKYUzInw%2BLudixXVtzs%3Dreserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Rupert Reynolds [rreyno...@cix.co.uk] > Sent: Sunday, March 27, 2022 4:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PL/I question > > Interesting. Thanks. > > I ask because many modern languages owe enough to C, or use libraries that > do, that it's become a working assumption that null, backslash and the like > will probably break something. > > I wrote a crude x86 compiler once, just to have a compiled language for my > own use that absolutely, definitely handled any byte value exactly the > same. It was supposed to be terse like C, but work more like PL/I. > > Oh, and I can't remember how far I got, but I started by abolishing = for > assignment. It was implicit in the syntax and = was only used for > comparison. I was young and foolish :-) > > Roops > > On Sun., Mar. 27, 2022, 18:10 Seymour J Metz, wrote: > >> There are no troublesome characters. If it's CHARZ 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). >> >> >> -- >> Shmuel (Seymour J.) Metz >> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7Csmetz3%40gmu.edu%7Ce9e248bf75944683e28408da106c86f3%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637840355848465546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=T0nyZXeRmQFRih61UBfLB4%2B%2FnKYUzInw%2BLudixXVtzs%3Dreserved=0 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf >> of Rupert Reynolds [rreyno...@cix.co.uk] >> Sent: Sunday, March 27, 2022 11:45 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: PL/I question >> >> Related: how does LE handle strings with embedded troublesome bytes such as >> x'00'? And is it different between PL/I and C? >> >> I am reading the PL/I Programming Guide, 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. >> >> Roos >> >> >> > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I question
True, but it's convenient to be able to write things like "foo := sine(bar := baz);". -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jay Maynard [jaymayn...@gmail.com] Sent: Monday, March 28, 2022 12:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I question Not me. Assignment is a much more common operation than comparison. It should be the shorter token. On Sun, Mar 27, 2022 at 9:52 PM Seymour J Metz wrote: > Personally, I wish that IBM had chosen ":=" for assignment. > -- Jay Maynard -- 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
