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: Ransoming a mainframe disk farm
My €0,02 Ransomware on z/OS is very unlikely, but it is possible. We cannot say it is impossible. The possibility depends on some circumstances which affect the results and possible prevention. It will be disscuessed. below (a little bit). Will backup help? NO! Backup may be last resort, especially for operating system itself and batch data. Not for online processing. In this case that could mean outage and data loss. Imagine lost of half day transactions in a bank... It is disaster for many businesses. What about backup from tape and forward recovery from transaction log? Hey, do you have log? Why can we assume the log is safe when we consider tables are "ransomwared"? (encrypted by hacker - let me use this neologism) And what about tape data? There were many voices about virtual tapes - saying it's not the same as physical tape. Oh, yes - physical cart is sexy. You can see it, you can touch it and you can remove it from ATL and keep on you desk. Or even send it to the vault. First: who removes tape from ATL? And why? Nowadays it can be poor replacement for second ATL in remote location. Or third copy. Always backlevel a little. And how can you know the data on tape is OK and it is not ransomwared copy of ransomwared dataset? Can I smell it? NO. Hello - is it possible hacker ransomwared backups on the tape? Why not? We just assumed he is able to ransomware DASD data. Such cases did take a place in Windows world. Conclusion: the only effective way is to do not allow ransomware attack to happen. Yes, we have to prevent it. All other ideas are like good advices to a guy after his house was already robbed. Too late. You already lost a lot. Reminder: all methods like backup, remote copy, third datacenter, tapes in vault, etc. will NOT help for ANY PROBLEM. They will help for some problems only. We are never 100% safe. It can be 99,9% or 99,%, but the gap exists. What's in the gap? Example: Terrorist attack can destroy our datacenter. There is no reason to assume the terrorists want to attack us, but we cannot say it is impossible. But it is also possible the terrorists would attack all our datacenters. BTW: such attack is not only matter of wall thickness, sometimes it can be false pizza courier with gun and hostages. And regarding IPL in VTS environment: AFAIK it is quite possible to IPL from virtual tape volume. IMHO tape IPL as problem recovery seems to be obsolete, maybe except poor installations. It is much more convenient to have rescue LPAR with small z/OS image. It is much faster and more convenient. Bigger shops may have rescue system cloned to any DASD box in the installation, it can be IPLable from any CPC, including DR site, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 04.09.2020 o 20:50, Jesse 1 Robinson pisze: It’s Friday, so don’t rag on me for venturing into IT fiction. No one has hit us with this challenge (yet), but it could happen. Ransomware is much in the news these days. As unlikely as it might be, some nefarious genius manages to lock you out of your entire disk farm and demands rubies and bitcoin to remove the lock. Meanwhile your shop is out of the water. You have everything meticulously mirrored to another site, but as with any good mirror, the lock has been reflected in your recovery site. The classic mainframe response--short of forking over the ransom--would be to IPL a standalone DSS restore tape, then locate and mount standard offload backup tapes. Restore enough key volumes to IPL a minimal system, then proceed to restore (all) other volumes. It will take a while, but it will work. Eventually. Now consider a smartly modern shop that has taken the advice of a generation of hired gurus and eliminated 'real tape' altogether. No more physical tapes. No more physical tape drives. What would be your sage advice? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 5
Re: RES: Architectural Level Sets
Yes, you are right. And it is described in the table, but it seems not clearly visible IMHO. Regarding performance - I did a lot of courses on MP 2000 and some on MP 3000. And yes, MP2k was not a daemon of speed. And there was some old stinking unpatched OS/390 system with ugly bug which forced me to change VSAM excercises just for the class. Old days... -- Radoslaw Skorupka Lodz, Poland W dniu 04.09.2020 o 16:34, Bodra - Pessoal pisze: MP3000 was considered a G5 since it could have IFL processor. MP 2000 was considered a G3 (??) and I remember to do some tests with a very early Linux using it with RAMACII. It was very very very slowly. Carlos Bodra IBM zEnterprise Certified São Paulo – SP – Brazil -Mensagem original- De: IBM Mainframe Discussion List Em nome de R.S. Enviada em: sexta-feira, 4 de setembro de 2020 10:10 Para: IBM-MAIN@LISTSERV.UA.EDU Assunto: Re: Architectural Level Sets W dniu 03.09.2020 o 17:37, Jim Elliott pisze: Tony, Check my CMOS Processor Table page at https://jlelliotton.blogspot.com/p/cmos-processor-table.html. I have the z/OS and z/VM level sets listed there. Comments to the table: 1. z/OS 1.1-1.5 were able to run on 9672 machines. z/OS 1.6 and later reuqired at least z900. 2. Multiprise 2000 and 3000 are mentioned in the table, but "not visible" I was looking for them in the notes, and found P/390 which misleaded me. Simple not "see above for Multiprise" would be convenient. Last, but not least: GOOD JOB! Thank you for the table. Note: For historical reasons I'm looking for information about earlier machines. Some details about HMC/SE equivalents, I/O cards, partitions, crypto hardware... Maybe someone knows such page? Regards == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Constant Identifiers
"No, FIXED BIN(15,0) is not an integer, and the precision rules can be very annoying to those with a Fortran mindset." Yes it is... Table 1. Data type definitions for PL/I Data typeDescriptionPL/I INT2 A 2-byte signed integer REAL FIXED BINARY (15,0) INT4 A 4-byte signed integer REAL FIXED BINARY (31,0) https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea300/ceea30016.htm Joe On Mon, Sep 7, 2020 at 12:15 AM 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. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > 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 > > > > -- > > 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: Constant Identifiers
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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ILR012W ALL LOCAL PAGING SPACE IS FULL OR BAD, ASM WAIT03C RSN=01
Thanks. I didn't know about that hidden panel. Yes, it does report on SCM; ASID=0003 JOB=RASP SLOTS= VIO= SCM=17A9 Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Monday, September 7, 2020 12:42 AM, Barbara Nitz wrote: > > ASSBNVSC and ASSBVSC tell you the number of slots each address space is > > > using. You can look at those in the dump. > > To make that easier, use the IPCS 'hidden' panels, specifically 2.6i (that's > the level2 toolkit). Use SLOTCNT, it will do the math for you and you'll see > the who gobbled up your aux. (I haven't tried it on SCM storage, so I just > hope it works for that as well as it did for DASD AUX.) > You can (and should) use the same command for comparison with the crashed > system. I believe this command works when set to active storage. You may be > surprised which address spaces use a lot regularly. > > Regards, Barbara > > --- > > 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: Ransoming a mainframe disk farm
Makes me wonder.. some network products have a 'total lockdown' mode that stops *anything* network. Like pulling the plug. IBM can have a similar thing for z/OS TCPIP/SNA networks but I reckon it's more effective if a similar lockdown (ugh) feature exists for RACF instead. Of course, this will mean a whole lot of things will now start failing (perhaps this feature can also write such lockdown-initiated violations into a special report), but it may be worth shuttering things down before things can get worse. Alternatively, storage boxes need to get intelligent with their metadata. - KB ‐‐‐ Original Message ‐‐‐ On Monday, September 7, 2020 5:04 PM, R.S. wrote: > My €0,02 > Ransomware on z/OS is very unlikely, but it is possible. We cannot say > it is impossible. > The possibility depends on some circumstances which affect the results > and possible prevention. It will be disscuessed. below (a little bit). > > Will backup help? NO! > Backup may be last resort, especially for operating system itself and > batch data. Not for online processing. In this case that could mean > outage and data loss. Imagine lost of half day transactions in a bank... > It is disaster for many businesses. > What about backup from tape and forward recovery from transaction log? > Hey, do you have log? Why can we assume the log is safe when we consider > tables are "ransomwared"? (encrypted by hacker - let me use this neologism) > And what about tape data? There were many voices about virtual tapes - > saying it's not the same as physical tape. Oh, yes - physical cart is > sexy. You can see it, you can touch it and you can remove it from ATL > and keep on you desk. Or even send it to the vault. > First: who removes tape from ATL? And why? Nowadays it can be poor > replacement for second ATL in remote location. Or third copy. Always > backlevel a little. > And how can you know the data on tape is OK and it is not ransomwared > copy of ransomwared dataset? Can I smell it? NO. > Hello - is it possible hacker ransomwared backups on the tape? Why not? > We just assumed he is able to ransomware DASD data. > Such cases did take a place in Windows world. > > Conclusion: the only effective way is to do not allow ransomware attack > to happen. Yes, we have to prevent it. All other ideas are like good > advices to a guy after his house was already robbed. Too late. You > already lost a lot. > > Reminder: all methods like backup, remote copy, third datacenter, tapes > in vault, etc. will NOT help for ANY PROBLEM. They will help for some > problems only. We are never 100% safe. It can be 99,9% or 99,%, but > the gap exists. What's in the gap? Example: Terrorist attack can destroy > our datacenter. There is no reason to assume the terrorists want to > attack us, but we cannot say it is impossible. But it is also possible > the terrorists would attack all our datacenters. BTW: such attack is not > only matter of wall thickness, sometimes it can be false pizza courier > with gun and hostages. > > And regarding IPL in VTS environment: AFAIK it is quite possible to IPL > from virtual tape volume. IMHO tape IPL as problem recovery seems to be > obsolete, maybe except poor installations. It is much more convenient to > have rescue LPAR with small z/OS image. It is much faster and more > convenient. Bigger shops may have rescue system cloned to any DASD box > in the installation, it can be IPLable from any CPC, including DR site, > etc. > > > --
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 integer arithmetic
The answer is here: https://www.ibm.com/support/knowledgecenter/SSY2V3_5.2.0/com.ibm.ent.pl1.zos.doc/lr/resarithoprt.html Joe On Mon, Sep 7, 2020 at 8:12 AM Robin Vowels wrote: > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
W dniu 07.09.2020 o 14:57, kekronbekron pisze: Makes me wonder.. some network products have a 'total lockdown' mode that stops *anything* network. Like pulling the plug. IBM can have a similar thing for z/OS TCPIP/SNA networks but I reckon it's more effective if a similar lockdown (ugh) feature exists for RACF instead. Of course, this will mean a whole lot of things will now start failing (perhaps this feature can also write such lockdown-initiated violations into a special report), but it may be worth shuttering things down before things can get worse. Alternatively, storage boxes need to get intelligent with their metadata. - KB I see no relationship to the ransomware problem, however in z/OS you can "totally lockdown" any network interface you want. Including offline the device and chpid. And this is IMHO good for Hollywood movies, not as real protection - this "plug out feature" would work ...when? After the hacker started encryption, or just two minutes before? Who/what recognize suspected activity? What if the activity was phony, just to run "plug out feaure"? My advice: 1. Only authorized users should have connectivity to the mainframe ...and any other resource. No more "any to any" company networks. Note: "authorized" in this point has nothing to do with a mainframe. Just Johny the Sysprog can connect to the host, but Jim the secretary cannot. 2. Only authorized users can logon. User, password, maybe MFA. Obvious. 3. Users are authorized to the resources they need, nothing more. Of course we do not talk about READ to SYS1.HELP, but it is good idea to not allow APF update to any TSO user. This is typical RACF responsibility. Lng story. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- 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: Ransoming a mainframe disk farm
"I see no relationship to the ransomware problem,..." The whole topic is a hypothetical discussion.. don't know what to say for the relation not being understandable. Just a thought for damage control.. Obviously, obvious security measures have still let this hypothetical problem through (either bypassed or less-than-optimal security measures).. so fiddling with user accesses at this point is irrelevant. Whole world knows how to prevent.. but actually doing it is a whole another matter of tools, processes, capabilities, and such. - KB ‐‐‐ Original Message ‐‐‐ On Monday, September 7, 2020 7:08 PM, R.S. wrote: > W dniu 07.09.2020 o 14:57, kekronbekron pisze: > > > Makes me wonder.. some network products have a 'total lockdown' mode that > > stops anything network. Like pulling the plug. > > IBM can have a similar thing for z/OS TCPIP/SNA networks but I reckon it's > > more effective if a similar lockdown (ugh) feature exists for RACF instead. > > Of course, this will mean a whole lot of things will now start failing > > (perhaps this feature can also write such lockdown-initiated violations > > into a special report), but it may be worth shuttering things down before > > things can get worse. > > Alternatively, storage boxes need to get intelligent with their metadata. > > > > - KB > > I see no relationship to the ransomware problem, however in z/OS you can > "totally lockdown" any network interface you want. Including offline the > device and chpid. And this is IMHO good for Hollywood movies, not as > real protection - this "plug out feature" would work ...when? After the > hacker started encryption, or just two minutes before? Who/what > recognize suspected activity? What if the activity was phony, just to > run "plug out feaure"? > > My advice: > > 1. Only authorized users should have connectivity to the mainframe > ...and any other resource. No more "any to any" company networks. Note: > "authorized" in this point has nothing to do with a mainframe. Just > Johny the Sysprog can connect to the host, but Jim the secretary cannot. > > 2. Only authorized users can logon. User, password, maybe MFA. Obvious. > 3. Users are authorized to the resources they need, nothing more. Of > course we do not talk about READ to SYS1.HELP, but it is good idea to > not allow APF update to any TSO user. This is typical RACF > responsibility. Lng story. > > -- > Radoslaw Skorupka > Lodz, Poland > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza > prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. > Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, > NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who disseminates > (copies, distributes) this message or takes any similar action, violates the > law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, > 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for > the Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.401.468 as at 1 January 2020. > > > 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: Constant Identifiers
No,it is not and that LE manual does not claim that it is. What that table describes is how to declare parameters of various types. It's analogous to they way you used to deal with character data in FORTRAN IV; you have to fudge using the available types. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Joe Monk Sent: Monday, September 7, 2020 8:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Constant Identifiers "No, FIXED BIN(15,0) is not an integer, and the precision rules can be very annoying to those with a Fortran mindset." Yes it is... Table 1. Data type definitions for PL/I Data typeDescriptionPL/I INT2 A 2-byte signed integer REAL FIXED BINARY (15,0) INT4 A 4-byte signed integer REAL FIXED BINARY (31,0) https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea300/ceea30016.htm Joe On Mon, Sep 7, 2020 at 12:15 AM 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. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > 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 > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ILR012W ALL LOCAL PAGING SPACE IS FULL OR BAD, ASM WAIT03C RSN=01 [EXTERNAL]
Flash Express is dead end. z14 and z15 has no Flash Express. Both have Virtual Flash Express, which is part of regular RAM assigned to this role. It is paid feature, IMHO it is much more efficient to buy this memory as central memory and have much less paging. Note, VFM is cut from same memory limit, so it decreases limit of memory. Of course this is a problem for those who has rich memory configuration. -- Radoslaw Skorupka Lodz, Poland W dniu 04.09.2020 o 16:35, Mark Jacobs pisze: On the z13 and z14 generations it was called Flash Express and connected using the PCIie interface. On the z15 generation it's even closer to the processor now. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Friday, September 4, 2020 9:47 AM, Pommier, Rex wrote: Thanks, Mark. I didn't know SCM was internal on the T02. I looked up SCM and the init and tuning guide (for 2.1) said it was part of auxiliary storage which in my mind has always been on external boxes. Rex -Original Message- From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of Mark Jacobs Sent: Friday, September 4, 2020 8:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ILR012W ALL LOCAL PAGING SPACE IS FULL OR BAD, ASM WAIT03C RSN=01 [EXTERNAL] SCM is internal to the z15-T02 processor. Someone was definitely using it up. Plenty of these messages in the system log. IRA265I 50% OF LOCAL PAGE DATA SET SPACE IS ALLOCATED Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Friday, September 4, 2020 8:54 AM, Pommier, Rex rpomm...@sfgmembers.com wrote: I know this is a long shot but did you check your storage array to make sure there wasn't a hiccup in it that momentarily disabled the SCM? Rex -Original Message- From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of Mark Jacobs Sent: Friday, September 4, 2020 7:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ILR012W ALL LOCAL PAGING SPACE IS FULL OR BAD, ASM WAIT03C RSN=01 [EXTERNAL] I looked last night. Didn't see any IRA messages that indicated who's consuming page space. We're 99.9% SCM for paging, just one small local page dataset for VIO. I'm conjecturing that that message isn't being issued with SCM. I'll double check the log though. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjacobs@protonma il.com ‐‐‐ Original Message ‐‐‐ On Friday, September 4, 2020 7:53 AM, Feller, Paul 02fc94e14c43-dmarc-requ...@listserv.ua.edu wrote: Mark, if you still have access to the SYSLOG for the lpar you could try to look for message IRA220I. The message will list the who was using up the AUX slots. The message can be displayed related to message IRA201E. Thanks.. Paul Feller GTS Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of Mark Jacobs Sent: Friday, September 4, 2020 6:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ILR012W ALL LOCAL PAGING SPACE IS FULL OR BAD, ASM WAIT03C RSN=01 [EXTERNAL] Someone used up the entire 128GB of SCM we've assigned to paging on one of our systems last night. AutoIPL took a SAD and then reipled, so the recovery went as well as can be expected. I'm not well versed in IPCS and so I was wondering if someone could give me hints on how to ascertain who did the deed. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail. ch _pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com&d=DwIG aQ &c=9g4MJkl2VjLjS6R4ei18BA&r=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45N yO c&m=nO6SfOLd2IEVNEntWxK_QaUVZZRVGGMEj4YS04NVCKU&s=1GFnCXMs-VFN7p-F-0 js syIy9eWosyO14SIXROftWg4&e= == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know
Re: PL/I integers (was: Constant Identifiers)
Did you read what I wrote? The code you wrote has nothing to do with the expression I gave. How about DECLARE (I, J) FIXED DECIMAL (15); I = 4; J = 3; PUT ((I/J*J)); -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 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 > > 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 -- 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)
"DECLARE (I, J) FIXED DECIMAL (15); I = 4; J = 3; PUT ((I/J*J));" Well, just doing the math, that should give an answer of 4. 4/3 * 3/1 = 4/1 = 4 ... Joe On Mon, Sep 7, 2020 at 9:15 AM Seymour J Metz wrote: > Did you read what I wrote? The code you wrote has nothing to do with the > expression I gave. How about > > DECLARE (I, J) FIXED DECIMAL (15); > I = 4; J = 3; > PUT ((I/J*J)); > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > 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 > > > > > 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I integers (was: Constant Identifiers)
All of this is really fascinating (and no, I'm not being facetious): A bunch of apparently knowledgeable PL/1 programmers cannot agree on a point that would seem to have a single indisputable answer. Rather than keep on saying "yes it is" / "no it isn't", couldn't one or two of you from both sides run a program demonstrating your claim? It would probably be necessary to define the compiler you're running, too. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Oh good. Now he'll be bi-ignorant. -Texas Agriculture Commissioner Jim Hightower when told that Texas Governor Bill Clements had been studying Spanish */ -- 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
"The maximum number of decimal digits allowed is 15. Default precision, assumed when no specification is made, is (5,0). The internal coded arithmetic form of decimal fixed-point data is packed decimal. Packed decimal is stored two digits to the byte, with a sign indication in the rightmost four bits of the rightmost byte. Consequently, a decimal fixed-point data item is always stored as an odd number of digits, even though the declaration of the variable may specify the number of digits (p) as an even number." Page 17 http://www.bitsavers.org/pdf/ibm/370/pli/GC33-0009-3_OS_PLI_Language_Reference_Jul74.pdf Joe On Mon, Sep 7, 2020 at 8:43 AM Robin Vowels wrote: > 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 > -- 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 3:01 AM, Paul Gilmartin wrote: If the number 3.1416 is used in more than one place in the program, or if it requires specific data or precision attributes, you must declare it as a named constant. In the olden days - years before the iPhone 6 was a thing - there were people called Technical Writers. Now-a-days we have Information Developers, referred to as ID. A few years back there seemed to be a religious phase where IBM ID went on a crusade to remove weasel words from documentation. (I'm no longer at IBM, so I don't know if this "phase" persists or not.) This seemed to take the form of global changes whenever a new version of the manual was being prepared, where every instance of a word on the "weasel list" was replaced by its more definite counterpart. For example, something like: "If the PDS directory is corrupt then the library scan may abend." became "If the PDS directory is corrupt then the library scan will abend." The latter sentence implies that if the library scan did not abend then the PDS directory cannot be corrupt in any way, which was not the original information that the author was trying to convey. You can -> You must It may -> It will It should - It will That last one is probably the sort of thing they were really trying to fix, I expect, as in: "If there is an I/O error, the scan should skip the bad block." "If there is an I/O error, the scan will skip the bad block." As it was, whole sections of text I wrote for our product took on meanings I hadn't intended, and sometimes the "edited" text became outright lies. Anyway, in case you haven't guessed yet, that's what I think happened in the quoted item from the PL/I LRM. Cheers, Greg -- 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
... and the compile options On 2020-09-07 10:48, Bob Bridges wrote: All of this is really fascinating (and no, I'm not being facetious): A bunch of apparently knowledgeable PL/1 programmers cannot agree on a point that would seem to have a single indisputable answer. Rather than keep on saying "yes it is" / "no it isn't", couldn't one or two of you from both sides run a program demonstrating your claim? It would probably be necessary to define the compiler you're running, too. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Oh good. Now he'll be bi-ignorant. -Texas Agriculture Commissioner Jim Hightower when told that Texas Governor Bill Clements had been studying Spanish */ -- 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: Ransoming a mainframe disk farm
Let me tell you why it is not such a hypothetical problem... As we all know, Microsoft now allows under Windows for Linux, Windows access to Linux datastores. So, imagine I have a mainframe data store mounted as a Linux FS on a Windows box running Windows for Linux. Now, the windows box gets ransom'd ... what happens to the Linux FS mounted on the Windows box? In case you dont know about it: https://docs.microsoft.com/en-us/windows/wsl/install-win10 Joe On Mon, Sep 7, 2020 at 8:47 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > "I see no relationship to the ransomware problem,..." > > The whole topic is a hypothetical discussion.. don't know what to say for > the relation not being understandable. > Just a thought for damage control.. > > Obviously, obvious security measures have still let this hypothetical > problem through (either bypassed or less-than-optimal security measures).. > so fiddling with user accesses at this point is irrelevant. > > Whole world knows how to prevent.. but actually doing it is a whole > another matter of tools, processes, capabilities, and such. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Monday, September 7, 2020 7:08 PM, R.S. > wrote: > > > W dniu 07.09.2020 o 14:57, kekronbekron pisze: > > > > > Makes me wonder.. some network products have a 'total lockdown' mode > that stops anything network. Like pulling the plug. > > > IBM can have a similar thing for z/OS TCPIP/SNA networks but I reckon > it's more effective if a similar lockdown (ugh) feature exists for RACF > instead. > > > Of course, this will mean a whole lot of things will now start failing > (perhaps this feature can also write such lockdown-initiated violations > into a special report), but it may be worth shuttering things down before > things can get worse. > > > Alternatively, storage boxes need to get intelligent with their > metadata. > > > > > > - KB > > > > I see no relationship to the ransomware problem, however in z/OS you can > > "totally lockdown" any network interface you want. Including offline the > > device and chpid. And this is IMHO good for Hollywood movies, not as > > real protection - this "plug out feature" would work ...when? After the > > hacker started encryption, or just two minutes before? Who/what > > recognize suspected activity? What if the activity was phony, just to > > run "plug out feaure"? > > > > My advice: > > > > 1. Only authorized users should have connectivity to the mainframe > > ...and any other resource. No more "any to any" company networks. > Note: > > "authorized" in this point has nothing to do with a mainframe. Just > > Johny the Sysprog can connect to the host, but Jim the secretary > cannot. > > > > 2. Only authorized users can logon. User, password, maybe MFA. Obvious. > > 3. Users are authorized to the resources they need, nothing more. Of > > course we do not talk about READ to SYS1.HELP, but it is good idea to > > not allow APF update to any TSO user. This is typical RACF > > responsibility. Lng story. > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > == > > > > Jeśli nie jesteś adresatem tej wiadomości: > > > > > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. > Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS > 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) > według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. > > > > If you are not the addressee of this message: > > > > - let us know by replying to this e-mail (thank you!), > > - delete this message permanently (including all the copies which you > have printed out or saved). > > This message may contain legally protected information, which may be > used exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, > 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court > for the Capital City of Warsaw, 12th Commercial Division of the National > Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share > capital amounting to PLN 169.401.468 as at 1 January 2020. > > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to
Re: Architectural Level Sets
On 2020-09-05 2:11 AM, Jim Mulder wrote: MVS had simulation for DAS in its program check handler, which allowed SP1.2 and its successors to run on machines which did not have DAS. DAS was first implemented via a microcode update on the 3033. It was never implemented on 158 and 168. Well, that explains it! :) Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Constant Identifiers
A good tech writer is a joy forever; one who will polish prose describing the delivered product in such a way that it still describes the delivered product. The other type is more common, and is reminicent of root canal. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Greg Price Sent: Monday, September 7, 2020 11:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Constant Identifiers On 2020-09-05 3:01 AM, Paul Gilmartin wrote: > If the number 3.1416 is used in more than one place in the program, > or if it requires specific data or precision attributes, you must declare > it as a named constant. In the olden days - years before the iPhone 6 was a thing - there were people called Technical Writers. Now-a-days we have Information Developers, referred to as ID. A few years back there seemed to be a religious phase where IBM ID went on a crusade to remove weasel words from documentation. (I'm no longer at IBM, so I don't know if this "phase" persists or not.) This seemed to take the form of global changes whenever a new version of the manual was being prepared, where every instance of a word on the "weasel list" was replaced by its more definite counterpart. For example, something like: "If the PDS directory is corrupt then the library scan may abend." became "If the PDS directory is corrupt then the library scan will abend." The latter sentence implies that if the library scan did not abend then the PDS directory cannot be corrupt in any way, which was not the original information that the author was trying to convey. You can -> You must It may -> It will It should - It will That last one is probably the sort of thing they were really trying to fix, I expect, as in: "If there is an I/O error, the scan should skip the bad block." "If there is an I/O error, the scan will skip the bad block." As it was, whole sections of text I wrote for our product took on meanings I hadn't intended, and sometimes the "edited" text became outright lies. Anyway, in case you haven't guessed yet, that's what I think happened in the quoted item from the PL/I LRM. Cheers, Greg -- 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: Ransoming a mainframe disk farm
So, does this mean that a cloud environment is more or less likely to be attacked than the same on premise environment? Such an attack could cause a major disruption in operations and thinking. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Sep 7, 2020, at 11:20 AM, Joe Monk wrote: > > Let me tell you why it is not such a hypothetical problem... > > As we all know, Microsoft now allows under Windows for Linux, Windows > access to Linux datastores. So, imagine I have a mainframe data store > mounted as a Linux FS on a Windows box running Windows for Linux. Now, the > windows box gets ransom'd ... what happens to the Linux FS mounted on the > Windows box? > > In case you dont know about it: > https://docs.microsoft.com/en-us/windows/wsl/install-win10 > > Joe > >> On Mon, Sep 7, 2020 at 8:47 AM kekronbekron < >> 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: >> >> "I see no relationship to the ransomware problem,..." >> >> The whole topic is a hypothetical discussion.. don't know what to say for >> the relation not being understandable. >> Just a thought for damage control.. >> >> Obviously, obvious security measures have still let this hypothetical >> problem through (either bypassed or less-than-optimal security measures)... >> so fiddling with user accesses at this point is irrelevant. >> >> Whole world knows how to prevent.. but actually doing it is a whole >> another matter of tools, processes, capabilities, and such. >> >> - KB >> >> ‐‐‐ Original Message ‐‐‐ >> On Monday, September 7, 2020 7:08 PM, R.S. >> wrote: >> >>> W dniu 07.09.2020 o 14:57, kekronbekron pisze: >>> -- 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)
What release of what compiler. I remember when IBM changed the default for FIXED BIN from (31,0) to (15,0) in order to eliminate some annoying anomalies that didn't occur in FORTRAN. Of course, back in those days there were fewer compiler options to muddy the waters. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Bob Bridges Sent: Monday, September 7, 2020 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I integers (was: Constant Identifiers) All of this is really fascinating (and no, I'm not being facetious): A bunch of apparently knowledgeable PL/1 programmers cannot agree on a point that would seem to have a single indisputable answer. Rather than keep on saying "yes it is" / "no it isn't", couldn't one or two of you from both sides run a program demonstrating your claim? It would probably be necessary to define the compiler you're running, too. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Oh good. Now he'll be bi-ignorant. -Texas Agriculture Commissioner Jim Hightower when told that Texas Governor Bill Clements had been studying Spanish */ -- 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: Ransoming a mainframe disk farm
Use DS8880 SafeGuardCopy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
WSL doesn't have anything to do with cloud. It's just the running of Linux within Windows, using bits of Hyper-V internally, I think. That said, Joe's point about securing this new vector is one to pay attention to. And since z/OS is also working on improving/expanding z/OS NFS implementation.. I'm sure IBM will make it as securable as possible, as always. - KB ‐‐‐ Original Message ‐‐‐ On Monday, September 7, 2020 8:56 PM, Steve Thompson wrote: > So, does this mean that a cloud environment is more or less likely to be > attacked than the same on premise environment? > > Such an attack could cause a major disruption in operations and thinking. > > Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct > mistaks > > > On Sep 7, 2020, at 11:20 AM, Joe Monk joemon...@gmail.com wrote: > > Let me tell you why it is not such a hypothetical problem... > > As we all know, Microsoft now allows under Windows for Linux, Windows > > access to Linux datastores. So, imagine I have a mainframe data store > > mounted as a Linux FS on a Windows box running Windows for Linux. Now, the > > windows box gets ransom'd ... what happens to the Linux FS mounted on the > > Windows box? > > In case you dont know about it: > > https://docs.microsoft.com/en-us/windows/wsl/install-win10 > > Joe > > > > > On Mon, Sep 7, 2020 at 8:47 AM kekronbekron < > > > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > > > "I see no relationship to the ransomware problem,..." > > > The whole topic is a hypothetical discussion.. don't know what to say for > > > the relation not being understandable. > > > Just a thought for damage control.. > > > Obviously, obvious security measures have still let this hypothetical > > > problem through (either bypassed or less-than-optimal security > > > measures)... > > > so fiddling with user accesses at this point is irrelevant. > > > Whole world knows how to prevent.. but actually doing it is a whole > > > another matter of tools, processes, capabilities, and such. > > > > > > - KB > > > > > > ‐‐‐ Original Message ‐‐‐ > > > On Monday, September 7, 2020 7:08 PM, R.S. r.skoru...@bremultibank.com.pl > > > wrote: > > > > > > > W dniu 07.09.2020 o 14:57, kekronbekron pisze: > > -- > > 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: Constant Identifiers
On Tue, 8 Sep 2020 01:04:43 +1000, Greg Price wrote: >On 2020-09-05 3:01 AM, Paul Gilmartin wrote: > >... A few years back there seemed to be a >religious phase where IBM ID went on a crusade to remove weasel words >from documentation. >... >As it was, whole sections of text I wrote for our product took on >meanings I hadn't intended, and sometimes the "edited" text became >outright lies. > Such changes should be subject to opt-in review by designers. >Anyway, in case you haven't guessed yet, that's what I think happened in >the quoted item from the PL/I LRM. > Yah. I recall a similar well-intentioned "crusade" to change "dataset" to "data set" everywhere (except, I hope, where used as a keyword). But "dataset" is creeping back into visibility. RCF submitted on apparent "outright lie" in the PL/I Ref. -- gil -- 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)
Hindsight? I never understood the purpose of the web, given that gopher and SGML were already here. All we were missing was a protocol called Mehitabel ;-) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Rupert Reynolds Sent: Sunday, September 6, 2020 5:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX true/false (was Constant Identifiers) Hindsight is a wonderful thing :-) On Sun, 6 Sep 2020 at 21:55, Seymour J Metz wrote: > You didn't read The World According to ARPA? As for the WWW, I'd rather we > had stuck to Gopher. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Rupert Reynolds > Sent: Sunday, September 6, 2020 4:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: REXX true/false (was Constant Identifiers) > > Loss of Internet access would have been sheer luxury! (insert The Four > Yorkshiremen sketch here) as this was the 1980s :-) The Internet was > there, but nobody had heard of it unless he was the sort of geek who > soldered his own modem cable, and WWW was probably not even a twinkle in > timbl's eye :-) > > On Sun, 6 Sep 2020 at 20:56, Seymour J Metz wrote: > > > All REXX implementations use 0 and 1 for false and true. But I agree that > > loss of Internet access is crippling. May this be the last time. > > > > > > -- > > Shmuel (Seymour J.) Metz > > -- 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: REXX true/false (was Constant Identifiers)
On Mon, 7 Sep 2020 18:52:55 +, Seymour J Metz wrote: >Hindsight? I never understood the purpose of the web, given that gopher and >SGML were already here. All we were missing was a protocol called Mehitabel ;-) > It's easy to understand. Just remember, you're not the customer; you're the product. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
While I really like your new term, "ransomwared", I have to disagree with the conclusion. Of course we need to try to prevent the attack, but we also need to have some kind of backup to get things at least somewhat back to normal. And that doesn't mean a single backup method for all kinds of data. For example, operating system changes don't happen every day, so as long as you get a system back up, it probably doesn't matter too much if all the PTF's are applied. DB2 is another story if you want something reasonably up-to-date. Hmm... maybe make a deal with the hacker at half price and only get the DB2 datasets back. Just kidding of course. It should be a moral decision to *never* pay any ransom, no matter what the cost to the business. Of course that will never fly in reality. On 9/7/2020 4:34 AM, R.S. wrote: Conclusion: the only effective way is to do not allow ransomware attack to happen. Yes, we have to prevent it. All other ideas are like good advices to a guy after his house was already robbed. Too late. You already lost a lot. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
> It should be a moral decision to *never* pay any ransom, no matter what the > cost to the business. Of course that will never fly in reality. All the InfoSec consultants talk a great game with "never pay" but the dirty little secret is that many or most do. In many cases it is not just the organization's data, it is the customers' lives. If you were a bank it would be great to say "we will never pay" but meanwhile how do your customers get their grocery money out of your ATMs? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Monday, September 7, 2020 4:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ransoming a mainframe disk farm While I really like your new term, "ransomwared", I have to disagree with the conclusion. Of course we need to try to prevent the attack, but we also need to have some kind of backup to get things at least somewhat back to normal. And that doesn't mean a single backup method for all kinds of data. For example, operating system changes don't happen every day, so as long as you get a system back up, it probably doesn't matter too much if all the PTF's are applied. DB2 is another story if you want something reasonably up-to-date. Hmm... maybe make a deal with the hacker at half price and only get the DB2 datasets back. Just kidding of course. It should be a moral decision to *never* pay any ransom, no matter what the cost to the business. Of course that will never fly in reality. -- 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)
"Mehitabel" - wow! You're a lot older than I assumed, Mr Metz! --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* In its state of nature [a dog] has a smell, and habits, which frustrate man's love; he washes it, house-trains it, teaches it not to steal, and is so enabled to love it completely. To the puppy, the whole proceeding would seem, if it were a theologian, to cast grave doubts on the "goodness" of man; but the full-grown and full-trained dog, larger, healthier and longer-lived than the wild dog, and admitted, as it were by Grace, to a whole world of affections, loyalties, interests and comforts entirely beyond its animal destiny, would have no such doubt. -C S Lewis, _The Problem of Pain_ */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, September 7, 2020 14:53 Hindsight? I never understood the purpose of the web, given that gopher and SGML were already here. All we were missing was a protocol called Mehitabel ;-) From: IBM Mainframe Discussion List on behalf of Rupert Reynolds Sent: Sunday, September 6, 2020 5:09 PM Hindsight is a wonderful thing :-) --- On Sun, 6 Sep 2020 at 21:55, Seymour J Metz wrote: > You didn't read The World According to ARPA? As for the WWW, I'd rather we > had stuck to Gopher. > > > From: Rupert Reynolds > Sent: Sunday, September 6, 2020 4:48 PM > > Loss of Internet access would have been sheer luxury! (insert The Four > Yorkshiremen sketch here) as this was the 1980s :-) The Internet was > there, but nobody had heard of it unless he was the sort of geek who > soldered his own modem cable, and WWW was probably not even a twinkle in > timbl's eye :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
I will tell you that when it happened to my client, the "ransom" was $1million. It was less expensive to lose a days work. in restoring from backups. Joe On Mon, Sep 7, 2020 at 6:53 PM Charles Mills wrote: > > It should be a moral decision to *never* pay any ransom, no matter what > the cost to the business. Of course that will never fly in reality. > > All the InfoSec consultants talk a great game with "never pay" but the > dirty little secret is that many or most do. In many cases it is not just > the organization's data, it is the customers' lives. If you were a bank it > would be great to say "we will never pay" but meanwhile how do your > customers get their grocery money out of your ATMs? > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tom Brennan > Sent: Monday, September 7, 2020 4:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Ransoming a mainframe disk farm > > While I really like your new term, "ransomwared", I have to disagree > with the conclusion. Of course we need to try to prevent the attack, > but we also need to have some kind of backup to get things at least > somewhat back to normal. And that doesn't mean a single backup method > for all kinds of data. For example, operating system changes don't > happen every day, so as long as you get a system back up, it probably > doesn't matter too much if all the PTF's are applied. DB2 is another > story if you want something reasonably up-to-date. > > Hmm... maybe make a deal with the hacker at half price and only get the > DB2 datasets back. Just kidding of course. It should be a moral > decision to *never* pay any ransom, no matter what the cost to the > business. Of course that will never fly in reality. > > -- > 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: REXX true/false (was Constant Identifiers)
Well, my father was a journalist and a bibiliophile, so I was exposed to the ambiance early on, but I only started programming in 1960, in tenth grade, on a machine that absolutely immunized me against nostalgia. If you think I'm old, I once saw a post from Werner Bucholz on this list. Gone, alas. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Bob Bridges Sent: Monday, September 7, 2020 8:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX true/false (was Constant Identifiers) "Mehitabel" - wow! You're a lot older than I assumed, Mr Metz! --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* In its state of nature [a dog] has a smell, and habits, which frustrate man's love; he washes it, house-trains it, teaches it not to steal, and is so enabled to love it completely. To the puppy, the whole proceeding would seem, if it were a theologian, to cast grave doubts on the "goodness" of man; but the full-grown and full-trained dog, larger, healthier and longer-lived than the wild dog, and admitted, as it were by Grace, to a whole world of affections, loyalties, interests and comforts entirely beyond its animal destiny, would have no such doubt. -C S Lewis, _The Problem of Pain_ */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, September 7, 2020 14:53 Hindsight? I never understood the purpose of the web, given that gopher and SGML were already here. All we were missing was a protocol called Mehitabel ;-) From: IBM Mainframe Discussion List on behalf of Rupert Reynolds Sent: Sunday, September 6, 2020 5:09 PM Hindsight is a wonderful thing :-) --- On Sun, 6 Sep 2020 at 21:55, Seymour J Metz wrote: > You didn't read The World According to ARPA? As for the WWW, I'd rather we > had stuck to Gopher. > > > From: Rupert Reynolds > Sent: Sunday, September 6, 2020 4:48 PM > > Loss of Internet access would have been sheer luxury! (insert The Four > Yorkshiremen sketch here) as this was the 1980s :-) The Internet was > there, but nobody had heard of it unless he was the sort of geek who > soldered his own modem cable, and WWW was probably not even a twinkle in > timbl's eye :-) -- 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: REXX true/false (was Constant Identifiers)
No, REXX has both DATATYPE CHAR and NUM strings.
Meanwhile C2D, D2X etc. would be useless if REXX could not then process
binary data - as in IPCS REXX:
ADDRESS IPCS
PSA_ADDRESS = ''
"EVALUATE" PSA_ADDRESS||. ,
"POSITION("X2D(224)") LENGTH(4) REXX(STORAGE(OLD_ASCB_ADDRESS))"
"EVALUATE" OLD_ASCB_ADDRESS||. ,
"POSITION("X2D(6C)") LENGTH(4) REXX(STORAGE(OLD_ASXB_ADDRESS))"
"EVALUATE" OLD_ASXB_ADDRESS||. ,
"POSITION("X2D(4)") LENGTH(4) REXX(STORAGE(TCB_CHAIN_START_ADDRESS))"
"EVALUATE" OLD_ASXB_ADDRESS||. ,
"POSITION("X2D(8)") LENGTH(4) REXX(STORAGE(TCB_CHAIN_STOP_ADDRESS))"
My mistake was to think that setting a variable to a quoted value, in
REXX, made that variable a type CHAR. But REXX considers it to be NUM if
it contains only numerics, regardless of whether its set value was
quoted or not. The oddity is that '0001'b etc. has DATATYPE CHAR
instead of NUM in REXX. This would not happen in Fortran (type logical)
or PL/I (DCL bit) or even COBOL (level-77 or -88, whatever it is).
On 07/09/2020 06:52, Seymour J Metz wrote:
> It isn't boolean; everything in REXX is a character string.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf of
> CM Poncelet
> Sent: Monday, September 7, 2020 1:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: REXX true/false (was Constant Identifiers)
>
> "ELSE IF ¬TRUE THEN " was just to demonstrate that "TRUE" is
> Boolean.
>
>
>
> On 07/09/2020 05:24, Seymour J Metz wrote:
>> First, that code is highly obfuscated. Why would you ever want to write "IF
>> foo & TRUE" instead of "IF foo"?
>>
>> Second, "ELSE IF ¬TRUE THEN foo" is dead code.
>>
>> Third, there are no booleans in REXX; the only data type is character string.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>>
>>
>> From: IBM Mainframe Discussion List on behalf of
>> CM Poncelet
>> Sent: Sunday, September 6, 2020 9:31 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: REXX true/false (was Constant Identifiers)
>>
>> In the following example,
>> TRUE = (1 - 1 = 0 & 1 ¬= 0) [or whatever is more appropriate],
>> it is then sufficient e.g. to code:
>> IF 4 ¬= 6 & TRUE THEN
>> ELSE IF ¬TRUE THEN
>>
>> I.e. TRUE can be defined as a Boolean '1'b in REXX, as per above.
>>
>> On 06/09/2020 20:43, Paul Gilmartin wrote:
>>> On Sun, 6 Sep 2020 12:03:18 -0400, scott Ford wrote:
>>>
I have done things like true =‘Y’ and then
If true
..
end
>>> What language? That would certainly be a syntax error in Rexx.
>>> And why? You could just omit the "if true" and code:
>>> do
>>> ..
>>> end
>>>
>>>
>>> n Sun, 6 Sep 2020 17:39:48 +, Seymour J Metz wrote:
A simple true=1;false=0 should suffice for clarity.
>>> Perhaps not to someone most familiar with shell scripts
>>> where the definitions are nearly the opposite (command
>>> status ($?) = 0 means success or true).
>>>
>>>
>>> On Sun, 6 Sep 2020 17:43:04 +0100, Rupert Reynolds wrote:
The advantage of Boolean is clarity in something like:-
/* Rexx */
TRUE = (1=1)
...
SELECT
WHEN logmode = "D4A32782" & (GotASCII & GotVBMrecord) THEN do
...
>>> Continuing your example, how would you have set the variables
>>> "GotASCII" and "GotVBMrecord" using the quasi-constants TRUE
>>> and FALSE? Does that enhance either clarity or economy of
>>> expression?
>>>
>>> I'm thinking that something like:
>>> if filetype=='ASCII' then GotASCII = TRUE; else GotASCII = FALSE
>>> would more succinctly be written:
>>> GotASCII = ( filetype=='ASCII' )
>>>
>>> But I've seen even worse, such as:
>>> if GotASCII = true then ...
>>> rather than simply:
>>> if GotASCII then ...
>>>
>>>
>>> On Sun, 6 Sep 2020 19:28:11 +, Seymour J Metz wrote:
Yes, you can count on the truth values of 0 and 1 in REXX never changing.
>>> Only if I spent $60 for the ANSI Standard .pdf
>>>
>>> -- gil
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> .
>>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> .
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
Re: Ransoming a mainframe disk farm
Poor product management on the part of the ransomware malefactors. At $50K they might have had a deal. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joe Monk Sent: Monday, September 7, 2020 5:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ransoming a mainframe disk farm I will tell you that when it happened to my client, the "ransom" was $1million. It was less expensive to lose a days work. in restoring from backups. -- 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)
No. REXX has built in functions to test the value of a string, but it's all
strings
foo =01
bar = '01'
baz = 0||1
all yield the same value,
shmuel@linux-gn5l:~> rexxtry
/usr/local/bin/rexxtry lets you interactively try REXX statements.
Each string is executed when you hit Enter.
Enter 'call tell' for a description of the features.
Go on - try a few... Enter 'exit' to end.
say datatype(01)
NUM
/usr/local/bin/rexxtry on LINUX
say datatype('01')
NUM
/usr/local/bin/rexxtry on LINUX
say datatype(0||1)
NUM
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of CM
Poncelet
Sent: Monday, September 7, 2020 9:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX true/false (was Constant Identifiers)
No, REXX has both DATATYPE CHAR and NUM strings.
Meanwhile C2D, D2X etc. would be useless if REXX could not then process
binary data - as in IPCS REXX:
ADDRESS IPCS
PSA_ADDRESS = ''
"EVALUATE" PSA_ADDRESS||. ,
"POSITION("X2D(224)") LENGTH(4) REXX(STORAGE(OLD_ASCB_ADDRESS))"
"EVALUATE" OLD_ASCB_ADDRESS||. ,
"POSITION("X2D(6C)") LENGTH(4) REXX(STORAGE(OLD_ASXB_ADDRESS))"
"EVALUATE" OLD_ASXB_ADDRESS||. ,
"POSITION("X2D(4)") LENGTH(4) REXX(STORAGE(TCB_CHAIN_START_ADDRESS))"
"EVALUATE" OLD_ASXB_ADDRESS||. ,
"POSITION("X2D(8)") LENGTH(4) REXX(STORAGE(TCB_CHAIN_STOP_ADDRESS))"
My mistake was to think that setting a variable to a quoted value, in
REXX, made that variable a type CHAR. But REXX considers it to be NUM if
it contains only numerics, regardless of whether its set value was
quoted or not. The oddity is that '0001'b etc. has DATATYPE CHAR
instead of NUM in REXX. This would not happen in Fortran (type logical)
or PL/I (DCL bit) or even COBOL (level-77 or -88, whatever it is).
On 07/09/2020 06:52, Seymour J Metz wrote:
> It isn't boolean; everything in REXX is a character string.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf of
> CM Poncelet
> Sent: Monday, September 7, 2020 1:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: REXX true/false (was Constant Identifiers)
>
> "ELSE IF ¬TRUE THEN " was just to demonstrate that "TRUE" is
> Boolean.
>
>
>
> On 07/09/2020 05:24, Seymour J Metz wrote:
>> First, that code is highly obfuscated. Why would you ever want to write "IF
>> foo & TRUE" instead of "IF foo"?
>>
>> Second, "ELSE IF ¬TRUE THEN foo" is dead code.
>>
>> Third, there are no booleans in REXX; the only data type is character string.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>>
>>
>> From: IBM Mainframe Discussion List on behalf of
>> CM Poncelet
>> Sent: Sunday, September 6, 2020 9:31 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: REXX true/false (was Constant Identifiers)
>>
>> In the following example,
>> TRUE = (1 - 1 = 0 & 1 ¬= 0) [or whatever is more appropriate],
>> it is then sufficient e.g. to code:
>> IF 4 ¬= 6 & TRUE THEN
>> ELSE IF ¬TRUE THEN
>>
>> I.e. TRUE can be defined as a Boolean '1'b in REXX, as per above.
>>
>> On 06/09/2020 20:43, Paul Gilmartin wrote:
>>> On Sun, 6 Sep 2020 12:03:18 -0400, scott Ford wrote:
>>>
I have done things like true =‘Y’ and then
If true
..
end
>>> What language? That would certainly be a syntax error in Rexx.
>>> And why? You could just omit the "if true" and code:
>>> do
>>> ..
>>> end
>>>
>>>
>>> n Sun, 6 Sep 2020 17:39:48 +, Seymour J Metz wrote:
A simple true=1;false=0 should suffice for clarity.
>>> Perhaps not to someone most familiar with shell scripts
>>> where the definitions are nearly the opposite (command
>>> status ($?) = 0 means success or true).
>>>
>>>
>>> On Sun, 6 Sep 2020 17:43:04 +0100, Rupert Reynolds wrote:
The advantage of Boolean is clarity in something like:-
/* Rexx */
TRUE = (1=1)
...
SELECT
WHEN logmode = "D4A32782" & (GotASCII & GotVBMrecord) THEN do
...
>>> Continuing your example, how would you have set the variables
>>> "GotASCII" and "GotVBMrecord" using the quasi-constants TRUE
>>> and FALSE? Does that enhance either clarity or economy of
>>> expression?
>>>
>>> I'm thinking that something like:
>>> if filetype=='ASCII' then GotASCII = TRUE; else GotASCII = FALSE
>>> would more succinctly be written:
>>> GotASCII = ( filetype=='ASCII' )
>>>
>>> But I've seen even worse, such as:
>>> if GotASCII = true then ...
>>> rather than simply:
>>> if GotASCII then ...
>>>
>>>
>>> On Sun, 6 Sep 2020 19:28:11 +, Seymour J Metz wrote:
Yes, you can count on the truth values of 0 and 1 in REXX never changing.
>>> Only if I spent $60 for the ANSI Standard .pdf
>>>
>>> -
Re: Ransoming a mainframe disk farm
Thinking about it ... it would be far simpler (than anti-ransomware capability in storage, or lock-all behaviour) if there were a RACF HealthChecker that looks for abnormal enc/dec activity. What 'normal' is can be learnt from a year's worth of actual enc/dec-related SMF data. - KB ‐‐‐ Original Message ‐‐‐ On Monday, September 7, 2020 9:43 PM, kekronbekron <02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > WSL doesn't have anything to do with cloud. > It's just the running of Linux within Windows, using bits of Hyper-V > internally, I think. > > That said, Joe's point about securing this new vector is one to pay attention > to. > And since z/OS is also working on improving/expanding z/OS NFS > implementation.. I'm sure IBM will make it as securable as possible, as > always. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Monday, September 7, 2020 8:56 PM, Steve Thompson ste...@copper.net > wrote: > > > > So, does this mean that a cloud environment is more or less likely to be > > attacked than the same on premise environment? > > Such an attack could cause a major disruption in operations and thinking. > > Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct > > mistaks > > > > > On Sep 7, 2020, at 11:20 AM, Joe Monk joemon...@gmail.com wrote: > > > Let me tell you why it is not such a hypothetical problem... > > > As we all know, Microsoft now allows under Windows for Linux, Windows > > > access to Linux datastores. So, imagine I have a mainframe data store > > > mounted as a Linux FS on a Windows box running Windows for Linux. Now, the > > > windows box gets ransom'd ... what happens to the Linux FS mounted on the > > > Windows box? > > > In case you dont know about it: > > > https://docs.microsoft.com/en-us/windows/wsl/install-win10 > > > Joe > > > > > > > On Mon, Sep 7, 2020 at 8:47 AM kekronbekron < > > > > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > > > > "I see no relationship to the ransomware problem,..." > > > > The whole topic is a hypothetical discussion.. don't know what to say > > > > for > > > > the relation not being understandable. > > > > Just a thought for damage control.. > > > > Obviously, obvious security measures have still let this hypothetical > > > > problem through (either bypassed or less-than-optimal security > > > > measures)... > > > > so fiddling with user accesses at this point is irrelevant. > > > > Whole world knows how to prevent.. but actually doing it is a whole > > > > another matter of tools, processes, capabilities, and such. > > > > > > > > - KB > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Monday, September 7, 2020 7:08 PM, R.S. > > > > r.skoru...@bremultibank.com.pl > > > > wrote: > > > > > > > > > W dniu 07.09.2020 o 14:57, kekronbekron pisze: > > > > -- > > 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: REXX true/false (was Constant Identifiers)
On Tue, 8 Sep 2020 02:30:01 +0100, CM Poncelet wrote: > >My mistake was to think that setting a variable to a quoted value, in >REXX, made that variable a type CHAR. But REXX considers it to be NUM if >it contains only numerics, regardless of whether its set value was > Not only numerics. For example, DATATYPE( '-1.2E+3' ) is NUM even though it contains 4 nonnumerics. >quoted or not. The oddity is that '0001'b etc. has DATATYPE CHAR > Quoting is a matter of representation, not of value. For example, A=='A' is true because the values are identical. >instead of NUM in REXX. This would not happen in Fortran (type logical) >or PL/I (DCL bit) or even COBOL (level-77 or -88, whatever it is). > Are you just learning that not all languages are the same? Rexx doesn't even have a level-77. But see: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ikja300/datatyp.htm Hmm. There I read: The DATATYPE function tests the meaning or type of characters in a string, independent of the encoding of those characters (for example, ASCII or EBCDIC). What is that trying to say? Does it mean that DATATYPE( '31'x ) (ASCII '1') and DATATYPE( 'F1'x ) (EBCDIC 1) are both NUM? (If they recognize DBCS, they should also recognize the prevalent UTF-8.) >On 07/09/2020 06:52, Seymour J Metz wrote: >> It isn't boolean; everything in REXX is a character string. >> What he said. -- gil -- 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)
You said, "It isn't boolean; everything in REXX is a character string."
I agree that "it's all strings", but not that "everything in REXX is a
*character* string."
Try the following:
ARG DEBUG
IF ABBREV(DEBUG,D,1) THEN ,
TRACE I
SIGNAL ON SYNTAX NAME ERROR0
TRUE = 1
SAY 'TRUE NUMERIC = 'TRUE
SAY 'DATATYPE TRUE = 'DATATYPE(TRUE)
IF ¬TRUE THEN SAY 'NOT TRUE NUMERIC'
IF TRUE THEN SAY 'YES, TRUE NUMERIC'
ERROR0:
SIGNAL ON SYNTAX NAME ERROR1
TRUE = '1'
SAY 'TRUE CHARACTER = 'TRUE
SAY 'DATATYPE TRUE = 'DATATYPE(TRUE)
IF ¬TRUE THEN SAY 'NOT TRUE CHARACTER'
IF TRUE THEN SAY 'YES, TRUE CHARACTER'
ERROR1:
SIGNAL ON SYNTAX NAME ERROR2
TRUE = '31'X
SAY 'TRUE HEXADECIMAL = 'TRUE
SAY 'DATATYPE TRUE = 'DATATYPE(TRUE)
IF ¬TRUE THEN SAY 'NOT TRUE HEXADECIMAL'
IF TRUE THEN SAY 'YES, TRUE HEXADECIMAL'
TRUE = '00110001'B
SAY 'TRUE BINARY HEX = 'TRUE
SAY 'DATATYPE TRUE = 'DATATYPE(TRUE)
IF ¬TRUE THEN SAY 'NOT TRUE BINARY HEX'
IF TRUE THEN SAY 'YES, TRUE BINARY HEX'
TRUE = '0001'B
SAY 'TRUE BINARY ONLY = 'TRUE
SAY 'DATATYPE TRUE = 'DATATYPE(TRUE)
IF ¬TRUE THEN SAY 'NOT TRUE BINARY ONLY'
IF TRUE THEN SAY 'YES, TRUE BINARY ONLY'
ERROR2:
SIGNAL ON SYNTAX NAME ERROR3
TRUE = '1'B
SAY 'TRUE BINARY BIT = 'TRUE
SAY 'DATATYPE TRUE = 'DATATYPE(TRUE)
IF ¬TRUE THEN SAY 'NOT TRUE BINARY BIT'
IF TRUE THEN SAY 'YES, TRUE BINARY BIT'
ERROR3:
EXIT 0
... which produces output:
TRUE NUMERIC = 1
DATATYPE TRUE = NUM
YES, TRUE NUMERIC
TRUE CHARACTER = 1
DATATYPE TRUE = NUM
YES, TRUE CHARACTER
TRUE HEXADECIMAL = 1
DATATYPE TRUE = NUM
YES, TRUE HEXADECIMAL
TRUE BINARY HEX = 1
DATATYPE TRUE = NUM
YES, TRUE BINARY HEX
TRUE BINARY ONLY = ? <--
DATATYPE TRUE = CHAR <--
TRUE BINARY BIT = ? <--
DATATYPE TRUE = CHAR <--
PRESS ANY KEY TO CONTINUE.
On 08/09/2020 02:44, Seymour J Metz wrote:
> No. REXX has built in functions to test the value of a string, but it's all
> strings
>
> foo =01
> bar = '01'
> baz = 0||1
>
> all yield the same value,
>
> shmuel@linux-gn5l:~> rexxtry
> /usr/local/bin/rexxtry lets you interactively try REXX statements.
> Each string is executed when you hit Enter.
> Enter 'call tell' for a description of the features.
> Go on - try a few... Enter 'exit' to end.
> say datatype(01)
> NUM
> /usr/local/bin/rexxtry on LINUX
> say datatype('01')
> NUM
> /usr/local/bin/rexxtry on LINUX
> say datatype(0||1)
> NUM
>
>
>
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf of
> CM Poncelet
> Sent: Monday, September 7, 2020 9:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: REXX true/false (was Constant Identifiers)
>
> No, REXX has both DATATYPE CHAR and NUM strings.
>
> Meanwhile C2D, D2X etc. would be useless if REXX could not then process
> binary data - as in IPCS REXX:
> ADDRESS IPCS
> PSA_ADDRESS = ''
> "EVALUATE" PSA_ADDRESS||. ,
> "POSITION("X2D(224)") LENGTH(4) REXX(STORAGE(OLD_ASCB_ADDRESS))"
> "EVALUATE" OLD_ASCB_ADDRESS||. ,
> "POSITION("X2D(6C)") LENGTH(4) REXX(STORAGE(OLD_ASXB_ADDRESS))"
> "EVALUATE" OLD_ASXB_ADDRESS||. ,
> "POSITION("X2D(4)") LENGTH(4) REXX(STORAGE(TCB_CHAIN_START_ADDRESS))"
> "EVALUATE" OLD_ASXB_ADDRESS||. ,
> "POSITION("X2D(8)") LENGTH(4) REXX(STORAGE(TCB_CHAIN_STOP_ADDRESS))"
>
>
> My mistake was to think that setting a variable to a quoted value, in
> REXX, made that variable a type CHAR. But REXX considers it to be NUM if
> it contains only numerics, regardless of whether its set value was
> quoted or not. The oddity is that '0001'b etc. has DATATYPE CHAR
> instead of NUM in REXX. This would not happen in Fortran (type logical)
> or PL/I (DCL bit) or even COBOL (level-77 or -88, whatever it is).
>
>
>
> On 07/09/2020 06:52, Seymour J Metz wrote:
>> It isn't boolean; everything in REXX is a character string.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>>
>>
>> From: IBM Mainframe Discussion List on behalf of
>> CM Poncelet
>> Sent: Monday, September 7, 2020 1:30 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: REXX true/false (was Constant Identifiers)
>>
>> "ELSE IF ¬TRUE THEN " was just to demonstrate that "TRUE" is
>> Boolean.
>>
>>
>>
>> On 07/09/2020 05:24, Seymour J Metz wrote:
>>> First, that code is highly obfuscated. Why would you ever want to write "IF
>>> foo & TRUE" instead of "IF foo"?
>>>
>>> Second, "ELSE IF ¬TRUE THEN foo" is dead code.
>>>
>>> Third, there are no booleans in REXX; the only data type is character
>>> string.
>>>
>>>
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>>
>>>
>>>
>>> From: IBM Mainframe Discussion List on behalf of
>>> CM Poncelet
>>> Sent: Sunday, September 6, 2020 9:31 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: R
Re: REXX true/false (was Constant Identifiers)
On Tue, 8 Sep 2020 03:33:18 +0100, CM Poncelet wrote: >You said, "It isn't boolean; everything in REXX is a character string." >� >I agree that "it's all strings", but not that "everything in REXX is a >*character* string." >� Persuing the Rexx Reference, SA32-0972-40, I find various instances of "character string" to mean strings for which DATATYPE() would not return CHAR. Particularly: Numbers: These are *character* strings consisting of one or more decimal digits, ... (emphasis added) What's your motivation and the motivation of the recondite examples you supplied (which I deleted) other than to dispute Shmuel's reasonable assertion. Would you consider an RCF to the Ref. requesting a clarification of "character string" >> On 07/09/2020 06:52, Seymour J Metz wrote: >>> It isn't boolean; everything in REXX is a character string. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
Kekronbekron wrote: >Thinking about it ... it would be far simpler (than anti-ransomware >capability in storage, or lock-all behaviour) if there were a RACF >HealthChecker that looks for abnormal enc/dec activity. What 'normal' >is can be learnt from a year's worth of actual enc/dec-related SMF >data. There are tools with capabilities like the ones you're describing. I have a couple comments: 1. There are some excellent ransomware (and similar non-ransomware disaster scenario) defenses available based on "out of band" controls and lockouts. IBM DS8000 SafeGuarded Copy is one such example, a really important one that's the foundation for some other valuable resiliency capabilities. However, I have worked with some organizations that still (also) want to maintain total physical and electronic (wired, wireless) separation for certain data. You can achieve total separation in a few ways, such as physical tape cartridges (usually WORM, preferably encrypted) ejected from tape libraries and vaulted "afar." Of course the costs include elongated Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs), but in some cases the costs are tolerable or at least tolerated. You cannot really keep data completely, absolutely separate if you care about retrieving it. You can only maintain separation with at least one adjective added, such as "physically and electronically separate storage media," which is not the same as "storage media separated from all possible human contact." The Voyager space probes, I think it's fair to say, will "never" be vulnerable to human contact. They contain tape drives and tape media, and they are currently electronically connected via NASA's Deep Space Network. Anyway, it depends on what you're trying to accomplish, but lots of options are available, not necessarily mutually exclusive. 2. If you need secure software build and deployment processes (yes, you do), I suggest contacting my employer. IBM has some super exciting new capabilities in this area, very cutting edge. They're grounded in mainframe technologies, whether in your data center, in the public cloud, or both. Mainframes often pioneer new capabilities that didn't exist in the entire industry. Here, too, that's what's happening. Ransomware is one clearcut demonstration that it doesn't particularly matter how terrific your data-focused defenses are if you have compromised applications, for it's applications -- program code -- that process(es) data. So you've got to approach security challenges holistically. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
Great notes, thanks! But real geeks know Warp Drive will be invented in 2063 and with that humans can easily catch up with Voyager, well, unless it becomes Vger. Here in the Los Angeles area a few years ago I went to see a guitar player and happened to meet a few guys who engineered and built parts of those probes - specifically the RTG power supplies. I could have listened to them talk about that stuff all evening. On 9/7/2020 9:57 PM, Timothy Sipples wrote: ... The Voyager space probes, I think it's fair to say, will "never" be vulnerable to human contact. -- 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)
A *character* string is either any string that has DATATYPE CHAR but not DATATYPE NUM, or is *any* string (and it might as well then be called 'anything string' instead of 'character string'). Q: "What's your motivation and the motivation of the recondite examples you supplied (which I deleted) other than to dispute Shmuel's reasonable assertion." A: "to dispute Shmuel's reasonable assertion." BTW "Are you just learning that not all languages are the same? Rexx doesn't even have a level-77." Nay, that REXX does not distinguish between quoted and unquoted data. On 08/09/2020 04:27, Paul Gilmartin wrote: > On Tue, 8 Sep 2020 03:33:18 +0100, CM Poncelet wrote: > >> You said, "It isn't boolean; everything in REXX is a character string." >> � >> I agree that "it's all strings", but not that "everything in REXX is a >> *character* string." >> � > Persuing the Rexx Reference, SA32-0972-40, I find various instances > of "character string" to mean strings for which DATATYPE() would > not return CHAR. Particularly: > Numbers: > These are *character* strings consisting of one or more decimal > digits, ... > (emphasis added) > > What's your motivation and the motivation of the recondite > examples you supplied (which I deleted) other than to > dispute Shmuel's reasonable assertion. > > Would you consider an RCF to the Ref. requesting a clarification of > "character string" > > >>> On 07/09/2020 06:52, Seymour J Metz wrote: It isn't boolean; everything in REXX is a character string. > -- 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
