Re: Extents more than One for load modules library
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Shannon Sent: Sunday, August 10, 2014 12:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents more than One for load modules library Load libraries go to more than one extent all the time. I don't believe there is any general problem. The problem occurs if the libraries are in the Linklist. A new extent won't be reflected in the DEB. For non-Linklist libraries it shouldn't be a problem until the next IPL or until a new Linklist Set is created.. Bob Shannon Rocket Software This problem is not limited to linklist libraries, but applies to all open libraries. E.g. if your IMS or CICS loadlib has extents and takes one more, also this is not reflected in the DEB and modules there cannot be found. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out BBC News - USB 'critically flawed' after bug discovery, researchers
On Sun, 10 Aug 2014 23:24:45 -0500, Mike Schwab mike.a.sch...@gmail.com wrote: You have to have firmware to run the USB. And in their example they were able to create a malicious firmware that nothing checks for. It's worse than that - they masquerade as something *else* that *IS* known about, and gets accepted. USB masquerading has been known for a while - but I like their phone trick. Shows imagination. And formatting the device is not going to get rid of it - outside of hardened systems, this is not likely to be stopped. Although you could have your own udev rules in Linux - nobody does that, they just use what Ubuntu sets up; which is basically create a new device node for anything that's plugged in. Whatever it happens to be pretending to be. I can't imagine mickeymouse ware doing any different. Seems businesses are slowly realising they can't allow anyone to plug USB in - but with BYOD now taking off, how's that going to be regulated ?. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out BBC News - USB 'critically flawed' after bug discovery, researchers
CM Poncelet wrote: Encrypt USBs with PGP and make them ISO-bootable, or use Aladdin eTokens I think you missed the point re. the actual technical issue. But it's not a bug, it's a feature. That's how USB has always worked. Pretty well anything you plug into a computer might cause havoc. A News Site exaggerating as usual. Just don't pass USB sticks around at a party. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rational Development and Test (RDT) aka z/OS on a PC
I, too, have suffered the same sort of troubles as Barbara, moving from v1.13 to v2.1 over four releases of the ADCD system image. Not wishing to steal any thunder from Barbara, the latest release (July 2014, v2.1), introduced the idea of a 'user' disk, volser S1CFG1, which is the residence disk for all the 'USER.xxx' libraries (These libraries are intended to hold user site modifications). This will make things slightly easier (but only slightly) when upgrading in the future. At the next upgrade, the S1CFG1 disk can be made part of the new configuration, for the time it takes to complete the job. During that time, the contents of libraries on S1CFG1 can be used as a source for equivalent libraries on the 'new' xxCFG1 disk. Regards John Compton Technical Support Engineer World Programming Limited john.comp...@teamwpc.co.uk -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: 08 August 2014 16:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rational Development and Test (RDT) aka z/OS on a PC Thanks for the detailed answer and ADCD review Barbara. Sounds like you should hire yourself out to the IBM ADCD packagers to teach them how to put that system together the professional way. :) Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barbara Nitz Sent: Friday, August 08, 2014 9:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rational Development and Test (RDT) aka z/OS on a PC Does the RDT license allow you to get updated ADCD images when they become available? E.G., when an ADCD version is made available for z/OS 2.1, can you load it on your RDT system? Yes, you can. Having gone through that two times (migration 1.10 - 1.13 and then moving 'the system' from running under VM at z/OS 1.13 to the RDT hardware), it's a pain: You essentially loose everything that you have customized in your previous system. Especially, if you're not sysprog enough to know that one never ever customizes anything in an SMPE maintained library. (Ask me how I know, especially the first time around). You come up with a new master catalog and a new RACF data base when you come up with a new ADCD system. There is no SMS environment to speak of on an ADCD system (just enough to get a logstream up for DB2). There is no HSM at all. If you have set up TCPIP any differently, you loose that as well. When I took over, I started out cleaning up catalogs - put everything not-system into a user catalog. Then I cleaned out RACF and essentially redefined everything from the ground up, deleting quite a bit and adding even more to have full coverage. And making sure that a group concept is followed. Did I mention that on an ADCD system none of the SMPE maintained libraries have data set profiles? I am almost at the point now where I can turn on PROTECTALL. I have also established an SMS environment (probably not a very good one, but it works) and set up HSM to at least migrate to level1 (there are no tapes configured on an ADCD system, although you could probably set some up) and to clean out all the temporary data sets. I have completely restructured JES2, after barely avoiding JES cold starts when (the minimal) spool ran full, so now we have a much larger spool on different volumes. Which required me to enlarge the checkpoint data sets substantially (we had run out of JOES at about 1300 jobs held and running in the system). I had started Health Checker on that ADCD system. It showed a lot of RC=12 exceptions. Can't the ADCD system be adjusted to use larger than MOD3 disks, just as one would do in a real system? I do realize that's a lot of work requiring a lot of system programmer-level changes, but I would think well worth the effort. I hope to have that work finished tomorrow, incidentally. I have recopied everything to mod9, cleaned up a very messy SMPE environment (I deleted about 800 target entries and 600 DLIB entries that haven't been in use for god knows how long, corrected quite a few references, added missing ones and so on...) Tomorrow I plan on IPLing from data sets at exactly the same software level, but copied from the new target libraries (did I mention that the SMPE that comes with ADCD would install into the live data sets?). If all goes well, then I'll also come up with a new master catalog that has the system indirectly catalogued so it will be a lot easier to IPL new maintenance or a new operating system. (Thanks to Mark Zelden for his onepack system - it helped a lot to see the actual steps needed to come up with a new master cat, especially when dealing with VSAM ZFSs.) All products that come with z/OS will then be in the master cat and not spread out haphazardly over some products catalog and the master cat. Barbara -- This message and any attachments are intended only for the use of the addressee
Re: Remote HMC or HMC with Remote Access
There is no problem connecting to the Integrated 3270 on a Remote HMC. But AFAIK there is no way to connect from a Browser session connected to an HMC that is local to the CEC. If so I would be happy to know how. Maybe we use different terminology, Tom ? What do you understand under 'HMC that is local to the CEC' ? Support Elements (SE's) ? I know SE's, local HMC's (located in our Datencenter) and Remote HMC's. And via my Office Browser Session to local HMC I can use Internal 3270 Interface for every LPAR of our CEC. ciao Lutz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Mass updates to the WLM policy.
Hi all, It has been asked before: is it possible to do mass updates to the WLM policy easily, e.g. add 200 Scheduling Enviroments to it, in batch or so? Apart from the replies, that the OP should not want to do what he wants to do, the general answer was NO. Is this still so? The z/OS MF interface seems to work the same way as the TSO interface: on update at a time. Has anyone found out the layout of the WLM policy PDS and a way or tool to manipulate (unload, update, reload) it in order to insert mass updates there? Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
At 06:26 + on 08/11/2014, Vernooij, CP (SPLXM) - KLM wrote about Re: Extents more than One for load modules library: This problem is not limited to linklist libraries, but applies to all open libraries. E.g. if your IMS or CICS loadlib has extents and takes one more, also this is not reflected in the DEB and modules there cannot be found. For CICS I have the impression that there is a REFRESH type command that can be issued to cause it to rebuild the control blocks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out BBC News - USB 'critically flawed' after bug discovery, researchers
On Mon, Aug 11, 2014 at 1:31 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: On Sun, 10 Aug 2014 23:24:45 -0500, Mike Schwab mike.a.sch...@gmail.com wrote: You have to have firmware to run the USB. And in their example they were able to create a malicious firmware that nothing checks for. It's worse than that - they masquerade as something *else* that *IS* known about, and gets accepted. USB masquerading has been known for a while - but I like their phone trick. Shows imagination. And formatting the device is not going to get rid of it - outside of hardened systems, this is not likely to be stopped. Although you could have your own udev rules in Linux - nobody does that, they just use what Ubuntu sets up; which is basically create a new device node for anything that's plugged in. Whatever it happens to be pretending to be. I can't imagine mickeymouse ware doing any different. Seems businesses are slowly realising they can't allow anyone to plug USB in - but with BYOD now taking off, how's that going to be regulated ?. I know it won't happen, but the desktop people could basically just snip the wires to the USB ports. Assuming that BYOD is forbidden at the installation. Of course, this means work for the desktop people. And that the PC likely can't be sold because it is damaged. It might be possible for MS to enhance Windows to have a registry entry to disallow USB to autoconnect a device. Perhaps this could be set to YES, NO or ASK. The Linux people could do something similar. I would bet the Linux people are more likely to do it and do it better. But I'm an known bigot on that. Shane ... -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
Saying that the problem of multiple extents applies only to LNKLST data sets is, I believe, incorrect. If the data set can be extended after it has been opened, whether the data set is in the LNKLST or some other concatenation, a fetch of a module that is now in the new extent will fail because the directory entry will point into the new extent and that extent will not be defined in the DEB. For something other than the LNKLST, the program could close and re-open (or the job could be started and restarted), but it still would have encountered the problem. For the LNKLST, if the job encountering the problem can be restarted, then creating and activating a new LNKLST set will work. If the job was already running and must stay running, then the unpredictably dangerous LNKLST UPDATE could be used after creating and activating. IBM Health Checker for z/OS Check(IBMCSV,CSV_LNKLST_SPACE) alerts you when you have a data set with more than 1 extent. FWIW, the limit of extents for the LNKLST is 255. The limit is something like 119 for normal concatenations (the number depends on how many data sets contributed to the total number of extents). And if you're wondering why it's different for the LNKLST, in part it relates to DEBCHK. The DEB for things opened by OPEN must fit within 4K. But the LNKLST is not opened by OPEN (and would not pass DEBCHK if that were tried). For the LNKLST, the limit comes from the number of extents being represented by a 1-byte field. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out BBC News - USB 'critically flawed' after bug discovery, researchers
John McKown wrote: I know it won't happen, but the desktop people could basically just snip the wires to the USB ports. Assuming that BYOD is forbidden at the installation. Of course, this means work for the desktop people. And that the PC likely can't be sold because it is damaged. No sidecutter needed. :-) You can use BIOS to disable the USB. Of course you need to protect the BIOS itself (with password for example) and motherboard (lock and key, lock-up box in somewhere) itself to prevent more tampering. You can ask BIOS, if available, that no boot is possible from an USB device. It might be possible for MS to enhance Windows to have a registry entry to disallow USB to autoconnect a device. Perhaps this could be set to YES, NO or ASK. It is possible. For all my PCs/Laptops, I turn it off because I hate 'pop-ups' asking me what to do. The same goes for DVD/CD/stiffies/etc. If I want something to run, I will ask, not waiting for lame pop-ups to act up. ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rational Development and Test (RDT) aka z/OS on a PC
This will make things slightly easier (but only slightly) when upgrading in the future. At the next upgrade, the S1CFG1 disk can be made part of the new configuration, for the time it takes to complete the job. During that time, the contents of libraries on S1CFG1 can be used as a source for equivalent libraries on the 'new' xxCFG1 disk. But it sounds like one still needs to go through quite some contortions to keep old settings/customization. In any case, I have now divorced just about everything from what is delivered on ADCD on my system, but I got a few scars this weekend when I could not get my system up because the linklist was broken (after the second library). The linklist was broken because IEBCOPY repeatedly destroyed the DCB on a copy operation for a PDSE: //COPY125 EXEC PGM=IEBCOPY,REGION=0M //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=SYS1.SIEALNKE //SYSUT2 DD DISP=(,KEEP),DSN=SYS1.SIEALNKE.N,DSNTYPE=LIBRARY, // SPACE=(TRK,(4000,0,0)),UNIT=3390,VOL=SER=TGT001 //SYSINDD * COPY INDD=SYSUT1,OUTDD=SYSUT2 This JCL results in IEBCOPY 'unloading' SYS1.SIEALNKE into arecfm=VS data set (but ending with RC=0) which brings linklist to a screeching halt. For other PDSEs, the same JCL (for other DSNs) dutifully copies the data set, using the DCB information from the input. I had 3 broken PDSEs, two of those in linklist. Brought IPL to a screeching halt, first with wait state for abend806, later when JES2 didn't come up. SYS1.SIEALNKE is the third data set in the linklst concatenation. When I fully specify the output DCB, the copy operation works. I don't know if this is specific to running iebcopy under z1090 code or not since servicelink doesn't let me login today. But I know of one other problem with IEBCOPY only occuring under z1090 code (we have it too, but not the fixing ptf since our distribution is too old.) Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
In 1407618715.59367.yahoomail...@web181002.mail.ne1.yahoo.com, on 08/09/2014 at 02:11 PM, Jon Perryman jperr...@pacbell.net said: What makes a fullscreen editor not a line mode editor? That you can't use it from a line-mode session. These days those are few and far between, but log on to TSO with TELNET (NVT, not TN3270) and try using ISPF. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
In 9036367415583024.wa.paulgboulderaim@listserv.ua.edu, on 08/09/2014 at 04:16 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: I suppose it's unfortunate that checking the return code is part of the macro language rather than of the host environment. Au contraire, it's fortunate. Anybody coding an edit macro is likely to need feedback from subcommands. I place a premium on economy of keystrokes and hand motion. Use vi. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New JVM based language.
An accessible reference for Wyvern is Nistor, Ligia, et al. Wyvern: A simple, typed, and pure object-oriented language. Proceedings of the 5th Workshop on MechAnisms for SPEcialization, Generalization and inHerItance. ACM, 2013. it is lucid enough, but to read it easily you will need to be comfortable with and tolerant of current computer-science jargon. (The acronym MASPEGH ought, for example, to have been strangled at or, better, aborted before birth, but it appears to be flourishing.) John McKown's notion that Wyvern is a JVM-based language would not, I must admit, have occurred to me; but it is a suggestive one. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rational Development and Test (RDT) aka z/OS on a PC
On Mon, 11 Aug 2014 07:45:36 -0500, Barbara Nitz wrote: //COPY125 EXEC PGM=IEBCOPY,REGION=0M //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=SYS1.SIEALNKE //SYSUT2 DD DISP=(,KEEP),DSN=SYS1.SIEALNKE.N,DSNTYPE=LIBRARY, // SPACE=(TRK,(4000,0,0)),UNIT=3390,VOL=SER=TGT001 //SYSINDD * COPY INDD=SYSUT1,OUTDD=SYSUT2 This JCL results in IEBCOPY 'unloading' SYS1.SIEALNKE into arecfm=VS data set (but ending with RC=0) which brings linklist to a screeching halt. For other PDSEs, the same JCL (for other DSNs) dutifully copies the data set, using the DCB information from the input. I had 3 broken PDSEs, two of those in linklist. Brought IPL to a screeching halt, first with wait state for abend806, later when JES2 didn't come up. SYS1.SIEALNKE is the third data set in the linklst concatenation. When I fully specify the output DCB, the copy operation works. I don't know if this is specific to running iebcopy under z1090 code or not since servicelink doesn't let me login today. But I know of one other problem with IEBCOPY only occuring under z1090 code (we have it too, but not the fixing ptf since our distribution is too old.) It's not specific to z1090. Change the SPACE-Paramter from SPACE=(TRK,(4000,0,0)) to SPACE=(TRK,(4000,0,1)). Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out BBC News - USB 'critically flawed' after bug discovery, researchers
Disallowance of USB insertion is fairly common in corporate PCs. Yes, it is a BIOS or registry setting. It is also possible to monitor and report USB insertions to a corporate security operations center. I have written software to do so for my employer. (OT to mainframes, of course.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, August 11, 2014 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Check out BBC News - USB 'critically flawed' after bug discovery, researchers On Mon, Aug 11, 2014 at 1:31 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: On Sun, 10 Aug 2014 23:24:45 -0500, Mike Schwab mike.a.sch...@gmail.com wrote: You have to have firmware to run the USB. And in their example they were able to create a malicious firmware that nothing checks for. It's worse than that - they masquerade as something *else* that *IS* known about, and gets accepted. USB masquerading has been known for a while - but I like their phone trick. Shows imagination. And formatting the device is not going to get rid of it - outside of hardened systems, this is not likely to be stopped. Although you could have your own udev rules in Linux - nobody does that, they just use what Ubuntu sets up; which is basically create a new device node for anything that's plugged in. Whatever it happens to be pretending to be. I can't imagine mickeymouse ware doing any different. Seems businesses are slowly realising they can't allow anyone to plug USB in - but with BYOD now taking off, how's that going to be regulated ?. I know it won't happen, but the desktop people could basically just snip the wires to the USB ports. Assuming that BYOD is forbidden at the installation. Of course, this means work for the desktop people. And that the PC likely can't be sold because it is damaged. It might be possible for MS to enhance Windows to have a registry entry to disallow USB to autoconnect a device. Perhaps this could be set to YES, NO or ASK. The Linux people could do something similar. I would bet the Linux people are more -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
On Mon, 11 Aug 2014 09:35:52 -0400, Shmuel Metz (Seymour J.) wrote: on 08/09/2014 at 04:16 PM, Paul Gilmartin said: I suppose it's unfortunate that checking the return code is part of the macro language rather than of the host environment. Au contraire, it's fortunate. Anybody coding an edit macro is likely to need feedback from subcommands. Surely one action choice might be to set the return code passed to the macro processor. But that shouldn't be the default, in deference to those who have expressed a phobia of performing a destructive action in a macro after a failed search. I place a premium on economy of keystrokes and hand motion. Use vi. I had that in mind. I do; with my data sets NFS-mounted to Solaris. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rational Development and Test (RDT) aka z/OS on a PC
On Mon, 11 Aug 2014 09:04:21 -0500, Norbert Friemel wrote: On Mon, 11 Aug 2014 07:45:36 -0500, Barbara Nitz wrote: //SYSUT2 DD DISP=(,KEEP),DSN=SYS1.SIEALNKE.N,DSNTYPE=LIBRARY, // SPACE=(TRK,(4000,0,0)),UNIT=3390,VOL=SER=TGT001 //SYSINDD * COPY INDD=SYSUT1,OUTDD=SYSUT2 This JCL results in IEBCOPY 'unloading' SYS1.SIEALNKE into arecfm=VS data set (but ending with RC=0) ... When I fully specify the output DCB, the copy operation works. ... It's not specific to z1090. Change the SPACE-Paramter from SPACE=(TRK,(4000,0,0)) to SPACE=(TRK,(4000,0,1)). Somewhat irritatingly, IEBCOPY exhibits this behavior even when I specify such as: SPACE=(TRK,(4000,0)),DSNTYPE=LIBRARY I think I should get a syntax error, rather, when a utility attempts to create a PS data set when DSNTYPE=LIBRARY has been specified. (Specifying DSORG=PO likewise avoids the problem.) Was the JCL supplied by IBM? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rational Development and Test (RDT) aka z/OS on a PC
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin On Mon, 11 Aug 2014 09:04:21 -0500, Norbert Friemel wrote: On Mon, 11 Aug 2014 07:45:36 -0500, Barbara Nitz wrote: //SYSUT2 DD DISP=(,KEEP),DSN=SYS1.SIEALNKE.N,DSNTYPE=LIBRARY, // SPACE=(TRK,(4000,0,0)),UNIT=3390,VOL=SER=TGT001 //SYSINDD * COPY INDD=SYSUT1,OUTDD=SYSUT2 This JCL results in IEBCOPY 'unloading' SYS1.SIEALNKE into arecfm=VS data set (but ending with RC=0) ... When I fully specify the output DCB, the copy operation works. ... It's not specific to z1090. Change the SPACE-Paramter from SPACE=(TRK,(4000,0,0)) to SPACE=(TRK,(4000,0,1)). Somewhat irritatingly, IEBCOPY exhibits this behavior even when I specify such as: SPACE=(TRK,(4000,0)),DSNTYPE=LIBRARY I think I should get a syntax error, rather, when a utility attempts to create a PS data set when DSNTYPE=LIBRARY has been specified. (Specifying DSORG=PO likewise avoids the problem.) This behavior should be APAR-able, IMO. -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New JVM based language.
On Mon, Aug 11, 2014 at 8:40 AM, John Gilmore jwgli...@gmail.com wrote: An accessible reference for Wyvern is Nistor, Ligia, et al. Wyvern: A simple, typed, and pure object-oriented language. Proceedings of the 5th Workshop on MechAnisms for SPEcialization, Generalization and inHerItance. ACM, 2013. it is lucid enough, but to read it easily you will need to be comfortable with and tolerant of current computer-science jargon. (The acronym MASPEGH ought, for example, to have been strangled at or, better, aborted before birth, but it appears to be flourishing.) John McKown's notion that Wyvern is a JVM-based language would not, I must admit, have occurred to me; but it is a suggestive one. Hum, I came to this conclusion (JVM based) based on the readme file which said that the JDK 8 was required and that Eclipse or IntelliJ are good IDEs for it. I have downloaded the code, but not reviewed it. John Gilmore, Ashland, MA 01721 - USA -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mass updates to the WLM policy.
IMO, no massive changes should *EVER* be added to a WLM Service Definition. *BEWARE* the law of unintended consequences. It is not a matter of the doing (via any method), it is a matter of the impact. Just my $0.02 USD worth. snip It has been asked before: is it possible to do mass updates to the WLM policy easily, e.g. add 200 Scheduling Enviroments to it, in batch or so? Apart from the replies, that the OP should not want to do what he wants to do, the general answer was NO. Is this still so? The z/OS MF interface seems to work the same way as the TSO interface: on update at a time. Has anyone found out the layout of the WLM policy PDS and a way or tool to manipulate (unload, update, reload) it in order to insert mass updates there? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
HIPER PTF SUP'd by non-HIPER?
It seems logical to me that a PTF which supersedes a HIPER PTF should itself be ASSIGNed the HIPER SOURCEID flag, but in one current instance (UI19849, which supersedes UI18382 whose APAR is flagged HIPER and DATALOSS) the superseding PTF is not flagged HIPER. Is that perhaps an oversight by the team that created UI19849? It is presumed that the fix in UI18382 is present in UI19849. TIA, -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MASPEGH? (was new JVM based language)
On Mon, Aug 11, 2014 at 8:40 AM, John Gilmore jwgli...@gmail.com wrote: snipped it is lucid enough, but to read it easily you will need to be comfortable with and tolerant of current computer-science jargon. (The acronym MASPEGH ought, for example, to have been strangled at or, better, aborted before birth, but it appears to be flourishing.) MASPEGH can't be flourishing too much. I'd never heard of it so I went to everybody's favorite search engine (GIYF in keeping with the spirit of the e-mail chain), and received a grand total of 0 hits. I did find 1 hit on something called MASPEGHI which, if this is what Mr. Gilmore is referring to, I completely agree. Mechanisms for Specialization, Generalization and Inheritance. Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
On Mon, Aug 11, 2014 at 8:35 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: snip I place a premium on economy of keystrokes and hand motion. Use vi. I have read of a professional author who uses ed on Linux for the initial writing of all his books. He just types in paragraph after paragraph, separated by two enter keystrokes. For writing, this seems like an excellent choice. It goes with what my creative writing teacher in High School said: Just let the words flow out, edit later. Not so useful for coding, especially in languages which are column oriented such as COBOL and Python. Really great for obfuscated C code, though. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
Barry Merrill wrote: If the loadlib has a very small blocksiZe (e.g. 1000 bytes, which we found in an IMS load library) that causes a frequently loaded module to be in MANY extents, there can be response time impact of seconds per transaction when those multi-extent members are loaded. Using half-track blocksize will mitigate against that kind of stupidity we found in our IMS folks who had chosen that small blocksize to make more use of disk space (which was itself an incorrect choice). It is often better to use 32,760 for load libraries than to use any smaller block size, and it's never worse. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
On 8/11/2014 6:47 AM, Peter Relson wrote: IBM Health Checker for z/OS Check(IBMCSV,CSV_LNKLST_SPACE) alerts you when you have a data set with more than 1 extent. I think this checks for linklist data sets allocated with a secondary space value, rather than a data set with existing secondary extents. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MASPEGH? (was new JVM based language)
I think it's MASPEGHI. And as someone who tries to keep up with programming languages I'm not much the wiser. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Pommier, Rex rpomm...@sfgmembers.com To: IBM-MAIN@listserv.ua.edu Date: 11/08/2014 16:23 Subject:MASPEGH? (was new JVM based language) Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Mon, Aug 11, 2014 at 8:40 AM, John Gilmore jwgli...@gmail.com wrote: snipped it is lucid enough, but to read it easily you will need to be comfortable with and tolerant of current computer-science jargon. (The acronym MASPEGH ought, for example, to have been strangled at or, better, aborted before birth, but it appears to be flourishing.) MASPEGH can't be flourishing too much. I'd never heard of it so I went to everybody's favorite search engine (GIYF in keeping with the spirit of the e-mail chain), and received a grand total of 0 hits. I did find 1 hit on something called MASPEGHI which, if this is what Mr. Gilmore is referring to, I completely agree. Mechanisms for Specialization, Generalization and Inheritance. Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
And in terms of data streams (Multi)Markdown is very much like that; The markup doesn't get in the way. So I use it for much of my writing. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@listserv.ua.edu Date: 11/08/2014 16:32 Subject:Re: another question about TSO edit command Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Mon, Aug 11, 2014 at 8:35 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: snip I place a premium on economy of keystrokes and hand motion. Use vi. I have read of a professional author who uses ed on Linux for the initial writing of all his books. He just types in paragraph after paragraph, separated by two enter keystrokes. For writing, this seems like an excellent choice. It goes with what my creative writing teacher in High School said: Just let the words flow out, edit later. Not so useful for coding, especially in languages which are column oriented such as COBOL and Python. Really great for obfuscated C code, though. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
In 1407629103.3949.yahoomail...@web181001.mail.ne1.yahoo.com, on 08/09/2014 at 05:05 PM, Jon Perryman jperr...@pacbell.net said: Would you use the Emacs editor outside x-windows? ObPedant Yes. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
In 53e72afc.5090...@kabelmail.de, on 08/10/2014 at 10:19 AM, Arthur Fichtl fich...@kabelmail.de said: I know, this is an issue to be discussed rather in ISPF-L It's on topic here, but there might be ISPF folks who don't read IBM-MAIN regularly. What I'm really missing in ISPF edit Can you work up a business case and submit a requirement to IBM? ·A command to convert special lines (like notelines) to datalines. Do you mean an EDIT macro command that is equivalent to the MD line command? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rational Development and Test (RDT) aka z/OS on a PC
In 3520720456398900.wa.nitzibmgmx@listserv.ua.edu, on 08/11/2014 at 07:45 AM, Barbara Nitz nitz-...@gmx.net said: The linklist was broken because IEBCOPY repeatedly destroyed the DCB on a copy operation for a PDSE: What did it do to the DCB information? // SPACE=(TRK,(4000,0,0)) Wasn't there a discussion here of zero directory counts a while back? This JCL results in IEBCOPY 'unloading' SYS1.SIEALNKE into arecfm=VS data set What happens if you use SPACE=(TRK,(4000,0,1))? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
In 4867121587620348.wa.bgodfrey.gzgmail@listserv.ua.edu, on 08/09/2014 at 08:55 PM, Bill Godfrey bgodfrey...@gmail.com said: Back in the 80's I worked at a place that had an IBM 7171 ASCII Device Attachment Control Unit, to which we could connect terminals like VT100's and, ISTR, a line from a modem to which a PC running a VT100 emulator could dial in, logon, and use ISPF. A session with a 3270 display protocol converter is not line mode. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rational Development and Test (RDT) aka z/OS on a PC
On Mon, 11 Aug 2014 09:24:00 -0500, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 11 Aug 2014 09:04:21 -0500, Norbert Friemel wrote: On Mon, 11 Aug 2014 07:45:36 -0500, Barbara Nitz wrote: //SYSUT2 DD DISP=(,KEEP),DSN=SYS1.SIEALNKE.N,DSNTYPE=LIBRARY, // SPACE=(TRK,(4000,0,0)),UNIT=3390,VOL=SER=TGT001 //SYSINDD * COPY INDD=SYSUT1,OUTDD=SYSUT2 This JCL results in IEBCOPY 'unloading' SYS1.SIEALNKE into arecfm=VS data set (but ending with RC=0) ... When I fully specify the output DCB, the copy operation works. ... It's not specific to z1090. Change the SPACE-Paramter from SPACE=(TRK,(4000,0,0)) to SPACE=(TRK,(4000,0,1)). Somewhat irritatingly, IEBCOPY exhibits this behavior even when I specify such as: SPACE=(TRK,(4000,0)),DSNTYPE=LIBRARY I think I should get a syntax error, rather, when a utility attempts to create a PS data set when DSNTYPE=LIBRARY has been specified. (Specifying DSORG=PO likewise avoids the problem.) The required parameters are in DFSMS Using Data Sets: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d4a0/3.8.5 The following parameters are both required to allocate a PDSE: - Specify DIR space (greater than zero) or DSORG=PO (partitioned organization) in the JCL, in the DYNALLOC macro, in the data class, or in the TSO ALLOCATE command. - Specify DSNTYPE=LIBRARY in the JCL, in the data class, in the TSO ALLOCATE command, using the LIKE keyword, or as the installation default specified in SYS1.PARMLIB. There's a Guideline that says the allocation fails without DIR space: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d4a0/3.8.4 That's not the case in z/OS 1.13 Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MASPEGH? (was new JVM based language)
It is sometimes MASPHEGI, as in the ACM proceedings I cited, Proceedings of the 5th Workshop on MechAnisms for SPEcialization, Generalization and inHerItance. With or without the terminal 'I' it is an abomination. I am delighted that google knows little about it, but there are circles in which it is now too common. (There may of course be an inside, coterie joke embedded in it: The high artificiality of the choice of 'H' and the second 'I' from 'inheritance' for inclusion in an acronym is suspicious.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MASPEGH? (was new JVM based language)
Agreed, it is a rather strange acronym. Maybe somebody in ACM likes the Muppets (MASPEGHI sounds suspiciously like Miss Piggy). smile Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Monday, August 11, 2014 11:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MASPEGH? (was new JVM based language) It is sometimes MASPHEGI, as in the ACM proceedings I cited, Proceedings of the 5th Workshop on MechAnisms for SPEcialization, Generalization and inHerItance. With or without the terminal 'I' it is an abomination. I am delighted that google knows little about it, but there are circles in which it is now too common. (There may of course be an inside, coterie joke embedded in it: The high artificiality of the choice of 'H' and the second 'I' from 'inheritance' for inclusion in an acronym is suspicious.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MASPEGH? (was new JVM based language)
Google thinks it's a city on Long Island. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Monday, August 11, 2014 6:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MASPEGH? (was new JVM based language) It is sometimes MASPHEGI, as in the ACM proceedings I cited, Proceedings of the 5th Workshop on MechAnisms for SPEcialization, Generalization and inHerItance. With or without the terminal 'I' it is an abomination. I am delighted that google knows little about it, but there are circles in which it is now too common. (There may of course be an inside, coterie joke embedded in it: The high artificiality of the choice of 'H' and the second 'I' from 'inheritance' for inclusion in an acronym is suspicious.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rational Development and Test (RDT) aka z/OS on a PC
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Norbert Friemel On Mon, 11 Aug 2014 09:24:00 -0500, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 11 Aug 2014 09:04:21 -0500, Norbert Friemel wrote: On Mon, 11 Aug 2014 07:45:36 -0500, Barbara Nitz wrote: //SYSUT2 DD DISP=(,KEEP),DSN=SYS1.SIEALNKE.N,DSNTYPE=LIBRARY, // SPACE=(TRK,(4000,0,0)),UNIT=3390,VOL=SER=TGT001 //SYSINDD * COPY INDD=SYSUT1,OUTDD=SYSUT2 This JCL results in IEBCOPY 'unloading' SYS1.SIEALNKE into arecfm=VS data set (but ending with RC=0) ... When I fully specify the output DCB, the copy operation works. ... It's not specific to z1090. Change the SPACE-Paramter from SPACE=(TRK,(4000,0,0)) to SPACE=(TRK,(4000,0,1)). Somewhat irritatingly, IEBCOPY exhibits this behavior even when I specify such as: SPACE=(TRK,(4000,0)),DSNTYPE=LIBRARY I think I should get a syntax error, rather, when a utility attempts to create a PS data set when DSNTYPE=LIBRARY has been specified. (Specifying DSORG=PO likewise avoids the problem.) The required parameters are in DFSMS Using Data Sets: http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/dgt2d4a0/3.8.5 The following parameters are both required to allocate a PDSE: - Specify DIR space (greater than zero) or DSORG=PO (partitioned organization) in the JCL, in the DYNALLOC macro, in the data class, or in the TSO ALLOCATE command. - Specify DSNTYPE=LIBRARY in the JCL, in the data class, in the TSO ALLOCATE command, using the LIKE keyword, or as the installation default specified in SYS1.PARMLIB. Hmmm I guess that makes the behavior non-APAR-able after all. There's a Guideline that says the allocation fails without DIR space: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d4a0/3.8.4 That's not the case in z/OS 1.13 Or not. -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out BBC News - USB 'critically flawed' after bug discovery, researchers
I probably did miss the point. What I meant was, if it is about *protecting* USB sticks from being tampered with, this can be done by encrypting them so that a password must be entered before they can be accessed at all. Obviously this won't work if the malware is present before the USB is encrypted, or if the USB's firmware has itself been corrupted, or if a non-encrypted USB can be plugged in. Formatting it and then shredding its free space (e.g. via PGP or Symantec's Norton Utilities etc.), or erasing all its contents (via PGP), should get rid of any uploaded malware data - if the USB's firmware has not itself been corrupted. Perhaps I am still missing the point ... 8-( David Stokes wrote: CM Poncelet wrote: Encrypt USBs with PGP and make them ISO-bootable, or use Aladdin eTokens I think you missed the point re. the actual technical issue. But it's not a bug, it's a feature. That's how USB has always worked. Pretty well anything you plug into a computer might cause havoc. A News Site exaggerating as usual. Just don't pass USB sticks around at a party. -- 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: Rational Development and Test (RDT) aka z/OS on a PC
On Mon, 11 Aug 2014 10:04:38 -0400, Shmuel Metz (Seymour J.) wrote: on 08/11/2014 at 07:45 AM, Barbara Nitz said: The linklist was broken because IEBCOPY repeatedly destroyed the DCB on a copy operation for a PDSE: What did it do to the DCB information? // SPACE=(TRK,(4000,0,0)) Wasn't there a discussion here of zero directory counts a while back? This JCL results in IEBCOPY 'unloading' SYS1.SIEALNKE into arecfm=VS data set What happens if you use SPACE=(TRK,(4000,0,1))? You ought to read threads in reverse order. Most of the questions you ask were answered by others before you posted. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
Educate me why 32k with wasted space on a track is better than half track; I do defer to your knowledge and do not argue you are not right, but why? Barry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Monday, August 11, 2014 10:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents more than One for load modules library Barry Merrill wrote: If the loadlib has a very small blocksiZe (e.g. 1000 bytes, which we found in an IMS load library) that causes a frequently loaded module to be in MANY extents, there can be response time impact of seconds per transaction when those multi-extent members are loaded. Using half-track blocksize will mitigate against that kind of stupidity we found in our IMS folks who had chosen that small blocksize to make more use of disk space (which was itself an incorrect choice). It is often better to use 32,760 for load libraries than to use any smaller block size, and it's never worse. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- 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: Extents more than One for load modules library
On Mon, 11 Aug 2014 16:23:31 -0500, Barry Merrill wrote: Educate me why 32k with wasted space on a track is better than half track; I do defer to your knowledge and do not argue you are not right, but why? The Binder exploits track balances. The wasted space you envision rarely occurs. If other utilities were similarly well-designed, 32k would always be optimal. If QSAM were as well-designed as Binder, 32k would more often be optimal. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
I have not researched this, at all, so this is an educational question. From your response to Barry it seems you are saying the Binder will write a 32K block and then write a short block on a track? If it is doing that, then how is that any better than a Half-track blocksize? It is still two blocks per track, or are you saying the binder wastes the remainder of the track? Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 11, 2014 5:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents more than One for load modules library On Mon, 11 Aug 2014 16:23:31 -0500, Barry Merrill wrote: Educate me why 32k with wasted space on a track is better than half track; I do defer to your knowledge and do not argue you are not right, but why? The Binder exploits track balances. The wasted space you envision rarely occurs. If other utilities were similarly well-designed, 32k would always be optimal. If QSAM were as well-designed as Binder, 32k would more often be optimal. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
There is something in what Paul Gilmartin writes, but note that what John Eells in fact wrote was begin extract It is often better to use 32,760 for load libraries than to use any smaller block size, and it's never worse. /end extract As I read this it disparages a block size B 32760, i.e. 2^15 - 1 = 32767 rounded down to the nearest fullword multiple. It is silent about half-track blocks for any current DASD geometry, which are in fact alluded to favorably elsewhere in the same post. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
On 2014-08-11 15:39, Blaicher, Christopher Y. wrote: I have not researched this, at all, so this is an educational question. From your response to Barry it seems you are saying the Binder will write a 32K block and then write a short block on a track? Yes (I have been told). If it is doing that, then how is that any better than a Half-track blocksize? It is still two blocks per track, or are you saying the binder wastes the remainder of the track? It does not waste the remainder of the track. But if Binder needs to write 32760 bytes, then: o If BLKSIZE=32760, it will write 32760 bytes followed by an IBG. o If BLKSIZE=27998, it will write 27998 bytes, an IBG, 4762 bytes, then an IBG. One more interblock gap, and correspondingly less space for the next block. The difference is tiny; I'll leave it to the Half-track advocates to concoct a scenario where Half-track is superior. And for PDSE, it scarcely matters. Everything is written in 4KiB pages. (But does Binder know this and ignore the specified BLKSIZE?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
On Mon, 11 Aug 2014 17:50:07 -0400, John Gilmore wrote: ... note that what John Eells in fact wrote was begin extract It is often better to use 32,760 for load libraries than to use any smaller block size, and it's never worse. /end extract As I read this it disparages a block size B 32760, i.e. 2^15 - 1 = 32767 rounded down to the nearest fullword multiple. ITYM doubleword. It is silent about half-track blocks for any current DASD geometry, which are in fact alluded to favorably elsewhere in the same post. You correctly and entirely quoted John Eells. The alluded to favorably elsewhere was a citation of Barry Merrills text, with which John E. was (slightly) disagreeing. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
Hi Folks, I've been following this thread. We have some of 32K, some of 1/2 block. BUT, we also have 19069, 6144, etc. Can I look at the load module size to determine if the module length is greater than the load library blocksize? Is this a productive use of time? Thanks! BobL -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 11, 2014 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents more than One for load modules library [ EXTERNAL ] On 2014-08-11 15:39, Blaicher, Christopher Y. wrote: I have not researched this, at all, so this is an educational question. From your response to Barry it seems you are saying the Binder will write a 32K block and then write a short block on a track? Yes (I have been told). If it is doing that, then how is that any better than a Half-track blocksize? It is still two blocks per track, or are you saying the binder wastes the remainder of the track? It does not waste the remainder of the track. But if Binder needs to write 32760 bytes, then: o If BLKSIZE=32760, it will write 32760 bytes followed by an IBG. o If BLKSIZE=27998, it will write 27998 bytes, an IBG, 4762 bytes, then an IBG. One more interblock gap, and correspondingly less space for the next block. The difference is tiny; I'll leave it to the Half-track advocates to concoct a scenario where Half-track is superior. And for PDSE, it scarcely matters. Everything is written in 4KiB pages. (But does Binder know this and ignore the specified BLKSIZE?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
My preceding post could have been worded more felicitously: one 3390 geometry had/has a notional track size of 56664 bytes and 16 tracks per cylinder. A half-track block for it is thus 28332 bytes in size, and this is certainly less than 32760. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
With today's Dasd and Processors it'd be way down on my list of tuning objectives. In a message dated 8/11/2014 5:01:58 P.M. Central Daylight Time, bles...@ofiglobal.com writes: We have some of 32K, some of 1/2 block. BUT, we also have 19069, 6144, etc. Can I look at the load module size to determine if the module length is greater than the load library blocksize? Is this a productive use of time? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
Barry Merrill wrote: Educate me why 32k with wasted space on a track is better than half track; I do defer to your knowledge and do not argue you are not right, but why? Basically, it's because RECFM=U does not behave like fixed blocks. The block size of a load library sets the maximum length of a text record. As Paul points out, the Binder uses TRKBAL to determine the space left on a track. IEBCOPY COPYMOD (not COPY) does the same. Both write short blocks when needed to maximize space utilization on every track. Block sizes below the maximum can only cause more text (and control) records to be written, to the detriment of space allocation and (sometimes) performance. Anyone can try this out: Copy LINKLIB using COPYMOD to different data sets with different block sizes and see what happens. You might find a block size past which things stop getting better, but you won't find a larger one that makes it worse. Search the archives for prior discussions on this with my name attached for far more detail. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
finger check(?) caused my JCL notify to malfunction
Somehow my notify on my job card does not notify me immediately at EOJ . When I log on to TSO, then I get the notify messages. Any thoughts on this. We are z/os 1.13 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finger check(?) caused my JCL notify to malfunction
On Mon, 11 Aug 2014 22:19:11 +, John Norgauer wrote: Somehow my notify on my job card does not notify me immediately at EOJ . When I log on to TSO, then I get the notify messages. Any thoughts on this. We are z/os 1.13 Where would you expect to be notified before you log on to TSO? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finger check(?) caused my JCL notify to malfunction
When the job ends, I always would get the notify message to my terminal from the broadcast facility. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 11, 2014 3:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction On Mon, 11 Aug 2014 22:19:11 +, John Norgauer wrote: Somehow my notify on my job card does not notify me immediately at EOJ . When I log on to TSO, then I get the notify messages. Any thoughts on this. We are z/os 1.13 Where would you expect to be notified before you log on to TSO? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finger check(?) caused my JCL notify to malfunction
This appears on the SYSLOG: SE '15.27.22 JOB15348 $HASP165 SYSJCNA ENDED AT N1 - JCL ERROR',LOGON, USER=(SYSJCN) But nothing displays on my terminal. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Norgauer Sent: Monday, August 11, 2014 3:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction When the job ends, I always would get the notify message to my terminal from the broadcast facility. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 11, 2014 3:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction On Mon, 11 Aug 2014 22:19:11 +, John Norgauer wrote: Somehow my notify on my job card does not notify me immediately at EOJ . When I log on to TSO, then I get the notify messages. Any thoughts on this. We are z/os 1.13 Where would you expect to be notified before you log on to TSO? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
Lester, Bob wrote: Hi Folks, I've been following this thread. We have some of 32K, some of 1/2 block. BUT, we also have 19069, 6144, etc. Can I look at the load module size to determine if the module length is greater than the load library blocksize? Is this a productive use of time? First, let me say that IBM recommends all IBM system software load libraries be allocated at a block size of 32,760. We have never yet extended that to application load libraries and I am not doing that here. What follows is thus just my unsupported opinion: I'd say any data set by data set analysis would not be worth your time. COPYMOD the modules to load libraries allocated at 32,760 and you will very likely save space and possibly improve performance. There is no downside I'm aware of, other than your time to do the copies, from a z/OS standpoint. Of course, if you have some vendor or home grown code somewhere that depends on the block size, all bets are off. I've never heard of any yet but that doesn't mean there is none. And I suppose something within z/OS could come out of the woodwork but nobody has come up with one since 1997 when I originally reached this conclusion for system software data sets. This is why ServerPac allocates all load libraries at a block size of 32,760. Whether this activity would be worthwhile depends. It's hard to quantify the benefits in advance without that data set by data set analysis, which would take more time than the COPYMODs. Note that 13030 and 19069 are historical maximum track lengths, for 3330, and 3350 respectively. They were good block sizes at the time for the same reasons that 32,760 is a good block size today. 6144 was chosen, IMO, due to fixed block thinking as a good submultiple of the track length, but full track blocking would actually have been better during the 2314/3330/3350 era. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finger check(?) caused my JCL notify to malfunction
Hi John, TSO PROFILE WTPMSG? BobL -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Norgauer Sent: Monday, August 11, 2014 4:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction [ EXTERNAL ] This appears on the SYSLOG: SE '15.27.22 JOB15348 $HASP165 SYSJCNA ENDED AT N1 - JCL ERROR',LOGON, USER=(SYSJCN) But nothing displays on my terminal. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Norgauer Sent: Monday, August 11, 2014 3:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction When the job ends, I always would get the notify message to my terminal from the broadcast facility. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 11, 2014 3:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction On Mon, 11 Aug 2014 22:19:11 +, John Norgauer wrote: Somehow my notify on my job card does not notify me immediately at EOJ . When I log on to TSO, then I get the notify messages. Any thoughts on this. We are z/os 1.13 Where would you expect to be notified before you log on to TSO? -- 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 This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finger check(?) caused my JCL notify to malfunction
May need to do a SYNC(Oper cmd from TSO) on Broadcast. In a message dated 8/11/2014 5:29:52 P.M. Central Daylight Time, jcnorga...@ucdavis.edu writes: This appears on the SYSLOG: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finger check(?) caused my JCL notify to malfunction
This appears on the SYSLOG: SE '15.27.22 JOB15348 $HASP165 SYSJCNA ENDED AT N1 - JCL ERROR',LOGON, USER=(SYSJCN) But nothing displays on my terminal. TSO PROFILE NOINTERCOM? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4c5c0/1.36.2 Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finger check(?) caused my JCL notify to malfunction
TSO PROFILE is set to WTPMSG -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lester, Bob Sent: Monday, August 11, 2014 3:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction Hi John, TSO PROFILE WTPMSG? BobL -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Norgauer Sent: Monday, August 11, 2014 4:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction [ EXTERNAL ] This appears on the SYSLOG: SE '15.27.22 JOB15348 $HASP165 SYSJCNA ENDED AT N1 - JCL ERROR',LOGON, USER=(SYSJCN) But nothing displays on my terminal. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Norgauer Sent: Monday, August 11, 2014 3:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction When the job ends, I always would get the notify message to my terminal from the broadcast facility. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 11, 2014 3:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction On Mon, 11 Aug 2014 22:19:11 +, John Norgauer wrote: Somehow my notify on my job card does not notify me immediately at EOJ . When I log on to TSO, then I get the notify messages. Any thoughts on this. We are z/os 1.13 Where would you expect to be notified before you log on to TSO? -- 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 This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. -- 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: finger check(?) caused my JCL notify to malfunction
Issued SYNC but no effect. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell Sent: Monday, August 11, 2014 3:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction May need to do a SYNC(Oper cmd from TSO) on Broadcast. In a message dated 8/11/2014 5:29:52 P.M. Central Daylight Time, jcnorga...@ucdavis.edu writes: This appears on the SYSLOG: -- 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: HIPER PTF SUP'd by non-HIPER?
On 08/11/2014 10:17 AM, Chase, John wrote: It seems logical to me that a PTF which supersedes a HIPER PTF should itself be ASSIGNed the HIPER SOURCEID flag, but in one current instance (UI19849, which supersedes UI18382 whose APAR is flagged HIPER and DATALOSS) the superseding PTF is not flagged HIPER. Is that perhaps an oversight by the team that created UI19849? It is presumed that the fix in UI18382 is present in UI19849. TIA, -jc- ... One could argue both ways: For someone who already has RECEIVED or APPLIED UI18321, it would be appropriate for UI19849 to only be marked HIPER if the additional fixes in it should also be categorized HIPER. On the other hand, if it is ever possible for someone requesting UI19849 and not already having the PTF it SUPs to not also RECEIVE UI18321, then the importance of applying a non-HIPER UI19849 in that environment might be overlooked. The problem here is that the HIPER designation is associated with a PTF when in some cases it might more appropriately be associated with specific APARs. An ERROR HOLD for the critical APAR(s) should of course be distributed via HOLDDATA for appropriate SMP/E elements affected by a HIPER PTF, but I think there is no way to distinguish critical ERROR holds worthy of a HIPER PTF from lesser errors if you haven't also received the PTF with the explicit HIPER identification. The simplest solution would be to just mark UI19849 HIPER but include (if the newest APARs are of lesser importance) a DOC HOLD indicating that UI19849 is not really HIPER if UI18321 is already or will be applied. This would require more manual effort if you had a good reason to apply HIPER PTFs but stay at the UI18321 level, but at least you have that option. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finger check(?) caused my JCL notify to malfunction
Thanks Norbert. That fixed the problem. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Norbert Friemel Sent: Monday, August 11, 2014 3:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finger check(?) caused my JCL notify to malfunction This appears on the SYSLOG: SE '15.27.22 JOB15348 $HASP165 SYSJCNA ENDED AT N1 - JCL ERROR',LOGON, USER=(SYSJCN) But nothing displays on my terminal. TSO PROFILE NOINTERCOM? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4c5c0/1.36.2 Norbert Friemel -- 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: Extents more than One for load modules library
On 08/11/2014 04:39 PM, Blaicher, Christopher Y. wrote: I have not researched this, at all, so this is an educational question. From your response to Barry it seems you are saying the Binder will write a 32K block and then write a short block on a track? If it is doing that, then how is that any better than a Half-track blocksize? It is still two blocks per track, or are you saying the binder wastes the remainder of the track? Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 11, 2014 5:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents more than One for load modules library On Mon, 11 Aug 2014 16:23:31 -0500, Barry Merrill wrote: Educate me why 32k with wasted space on a track is better than half track; I do defer to your knowledge and do not argue you are not right, but why? The Binder exploits track balances. The wasted space you envision rarely occurs. If other utilities were similarly well-designed, 32k would always be optimal. If QSAM were as well-designed as Binder, 32k would more often be optimal. -- gil Because of many embedded blocks with control information and varying CSECT sizes load modules always contain a mix of physical block sizes in combinations impossible for mere mortals to predict, and my guess is that some of those smaller blocks aren't split across tracks but may just be displaced to the next track if a potentially large text block earlier in the track is constrained by a smaller block size and splits adding another inter-block gap. A large TEXT block at the end of a track may be split across tracks to fit available remaining space, but not all TEXT blocks are large so such splits do not always occur. Empirical evidence seems to support that 32760 gives slightly fewer total blocks for a module, which translates into slightly better track utilization and slightly better I/O performance. The only down side is that I/O buffers for the loadlib must be larger to reflect the larger max size, but memory is so plentiful these days that's no longer a significant issue. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HIPER PTF SUP'd by non-HIPER?
HIPER is never carried forward to a superseding PTF. HIPER requests that you immediately install a PTF and ignore your PTF installation process. You apply this PTF to your production systems far sooner than typical. The superseding PTF fixes more than just the HIPER situation and possibly requires other PTF's. A HIPER PTF must change as little code as possible. Often, there will be 2 PTF's caused by a HIPER situation. The HIPER PTF eliminates the HIPER situation but may not be the complete solution. The second PTF fixes what the HIPER did not fix. Jon Perryman On Monday, August 11, 2014 8:17 AM, Chase, John jch...@ussco.com wrote: It seems logical to me that a PTF which supersedes a HIPER PTF should itself be ASSIGNed the HIPER SOURCEID flag, but in one current instance (UI19849, which supersedes UI18382 whose APAR is flagged HIPER and DATALOSS) the superseding PTF is not flagged HIPER. Is that perhaps an oversight by the team that created UI19849? It is presumed that the fix in UI18382 is present in UI19849. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
You really get 16 tracks per cylinder? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Monday, August 11, 2014 3:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents more than One for load modules library My preceding post could have been worded more felicitously: one 3390 geometry had/has a notional track size of 56664 bytes and 16 tracks per cylinder. A half-track block for it is thus 28332 bytes in size, and this is certainly less than 32760. John Gilmore, Ashland, MA 01721 - USA -- 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: Extents more than One for load modules library
ISPF 3.4, among other tools, can provide the size of the load module. But the data in the load module need not include an area defined with a large DS. Thus you could have a very large module that occupies only a little space on disk. The net result is that load module size does not tell you if any of the records could benefit from a larger blocksize. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lester, Bob Sent: Monday, August 11, 2014 3:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents more than One for load modules library Hi Folks, I've been following this thread. We have some of 32K, some of 1/2 block. BUT, we also have 19069, 6144, etc. Can I look at the load module size to determine if the module length is greater than the load library blocksize? Is this a productive use of time? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MASPEGH? (was new JVM based language)
Charles, Yeah actually very funny Scott ford www.identityforge.com from my IPAD On Aug 11, 2014, at 12:49 PM, Charles Mills charl...@mcn.org wrote: Google thinks it's a city on Long Island. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Monday, August 11, 2014 6:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MASPEGH? (was new JVM based language) It is sometimes MASPHEGI, as in the ACM proceedings I cited, Proceedings of the 5th Workshop on MechAnisms for SPEcialization, Generalization and inHerItance. With or without the terminal 'I' it is an abomination. I am delighted that google knows little about it, but there are circles in which it is now too common. (There may of course be an inside, coterie joke embedded in it: The high artificiality of the choice of 'H' and the second 'I' from 'inheritance' for inclusion in an acronym is suspicious.) -- 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
INITILAIZE COST
Hello. We have a array like this , what would be best way to initlaize this array in terms of performance ? 01 EXAMPLE-TABLE. 05 MY-TABLE. 10 TABLE-ENTRY OCCURS TIMES. 15 FIRST-NAME PIC X(15). 15 LAST-NAME PIC X(15). 15 SEX-CODE PIC X. 15 DOB. 20 DOB- PIC 9(4). 20 DOB-MM PIC 99. 20 DOB-DD PIC 99. 15 SSNPIC 9(9). 15 SALARY PIC S9(9)V99 COMP-3. Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out BBC News - USB 'critically flawed' after bug discovery, researchers
Encryption or doing something with USB will not solve the problem. The flaw is with Plug-n-play and well known since it's early days. The exposure is not a surprise. In the past, it was considered a non-problem mostly because USB was device specific (e.g. disks, mouse, keyboard, ...). Virus scanners now typically scan removeable storage when they come online (CD's, DVD's, USB memory sticks / disks, This eliminated the biggest risk with Plug-n-play because you typically knew the USB devices you plugged in.. USB (and probably firewire too) has always supported multiple active devices on a single USB connection. What has changed was the introduction of smart devices. Most recognizable would be smart phones. These devices generally don't have virus scanners so the introduction of a virus is fairly simple. That virus could easily send a plug-n-play device request over USB for any supported plug-n-play device driver and use any of that devices features to invade your system. Hackers don't need to build any special plug-n-play device driver because most plug-n-play operating systems come with many drivers just on the off chance you might need it. For example, USB keyboard, mouse and secondary display drivers already exist. With these 3 devices, a hacker would have full control of your system and could do anything they want. I'm sure there must be other USB device drivers that a hacker can exploit. Many parents would never let their kids on their computers just to avoid viruses. If their kids asked their parents to copy photo's from their smart phones, they never think about the exposure and will simply connect it. Jon Perryman. On Monday, August 11, 2014 11:55 AM, CM Poncelet ponce...@bcs.org.uk wrote: I probably did miss the point. What I meant was, if it is about *protecting* USB sticks from being tampered with, this can be done by encrypting them so that a password must be entered before they can be accessed at all. Obviously this won't work if the malware is present before the USB is encrypted, or if the USB's firmware has itself been corrupted, or if a non-encrypted USB can be plugged in. Formatting it and then shredding its free space (e.g. via PGP or Symantec's Norton Utilities etc.), or erasing all its contents (via PGP), should get rid of any uploaded malware data - if the USB's firmware has not itself been corrupted. Perhaps I am still missing the point ... 8-( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INITILAIZE COST
On 8/11/2014 7:37 PM, Ron Thomas wrote: Hello. We have a array like this , what would be best way to initlaize this array in terms of performance ? 01 EXAMPLE-TABLE. 05 MY-TABLE. 10 TABLE-ENTRY OCCURS TIMES. 15 FIRST-NAME PIC X(15). 15 LAST-NAME PIC X(15). 15 SEX-CODE PIC X. 15 DOB. 20 DOB- PIC 9(4). 20 DOB-MM PIC 99. 20 DOB-DD PIC 99. 15 SSNPIC 9(9). 15 SALARY PIC S9(9)V99 COMP-3. Thanks Ron T Put a VALUE clause on each elementary item. -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INITILAIZE COST
Don't. Use occurs depending on or keep track of number of entries in a separate variable. Populate entries as needed. All valid entrIes are initialized when populated. Restrict subsequent operations to number of rows in table. On Aug 11, 2014 6:37 PM, Ron Thomas ron5...@gmail.com wrote: Hello. We have a array like this , what would be best way to initlaize this array in terms of performance ? 01 EXAMPLE-TABLE. 05 MY-TABLE. 10 TABLE-ENTRY OCCURS TIMES. 15 FIRST-NAME PIC X(15). 15 LAST-NAME PIC X(15). 15 SEX-CODE PIC X. 15 DOB. 20 DOB- PIC 9(4). 20 DOB-MM PIC 99. 20 DOB-DD PIC 99. 15 SSNPIC 9(9). 15 SALARY PIC S9(9)V99 COMP-3. Thanks Ron T -- 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: finger check(?) caused my JCL notify to malfunction
On 2014-08-11 16:24, John Norgauer wrote: When the job ends, I always would get the notify message to my terminal from the broadcast facility. While your terminal is not logged on to TSO? I'm astonished. Is the data cable even connected? -Original Message- From: Paul Gilmartin Sent: Monday, August 11, 2014 3:22 PM On Mon, 11 Aug 2014 22:19:11 +, John Norgauer wrote: Somehow my notify on my job card does not notify me immediately at EOJ . When I log on to TSO, then I get the notify messages. Any thoughts on this. We are z/os 1.13 Where would you expect to be notified before you log on to TSO? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents more than One for load modules library
On Mon, 11 Aug 2014 17:22:07 -0700, retired mainframer wrote: You really get 16 tracks per cylinder? Only with data compression. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MASPEGH? (was new JVM based language)
On Mon, 11 Aug 2014 12:20:15 -0400, John Gilmore wrote: It is sometimes MASPHEGI, as in the ACM proceedings I cited, Proceedings of the 5th Workshop on MechAnisms for SPEcialization, Generalization and inHerItance. Sounds vaguely Italian. With or without the terminal 'I' it is an abomination. ... I decided I was sated with esoteric languages when I stumbled upon (but never attempted to master) (NSFW?): http://en.wikipedia.org/wiki/%42%72%61%69%6E%66%75%63%6B -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INITILAIZE COST
Heavy emphasis on that last sentence. Just had a customer who didn't keep track of the number of entries in his COBOL table while adding new ones. Ended up adding entries way beyond the end of his table leading to altering the fields following the table to wrong values leading to very strange scary looking dumps that seemed to point to big problems in unsupported code! But, nope, simple, his table got bigger than the definition. Duffy Nightingale Sound Software Printing, Inc. du...@soundsoftware.us www.soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although Sound Software Printing, Inc. attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. On Aug 11, 2014, at 6:43 PM, Sam Siegel s...@pscsi.net wrote: Don't. Use occurs depending on or keep track of number of entries in a separate variable. Populate entries as needed. All valid entrIes are initialized when populated. Restrict subsequent operations to number of rows in table. On Aug 11, 2014 6:37 PM, Ron Thomas ron5...@gmail.com wrote: Hello. We have a array like this , what would be best way to initlaize this array in terms of performance ? 01 EXAMPLE-TABLE. 05 MY-TABLE. 10 TABLE-ENTRY OCCURS TIMES. 15 FIRST-NAME PIC X(15). 15 LAST-NAME PIC X(15). 15 SEX-CODE PIC X. 15 DOB. 20 DOB- PIC 9(4). 20 DOB-MM PIC 99. 20 DOB-DD PIC 99. 15 SSNPIC 9(9). 15 SALARY PIC S9(9)V99 COMP-3. Thanks Ron T -- 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: INITILAIZE COST
On 8/11/2014 7:43 PM, Sam Siegel wrote: Don't. Use occurs depending on or keep track of number of entries in a separate variable. Populate entries as needed. All valid entrIes are initialized when populated. Restrict subsequent operations to number of rows in table. Well, of course, we don't really know what the OP wanted. In terms of performance, you want to code a VALUE clause on each elementary item. This results in the whole table being initialized (assuming COBOL 4.2 (I think) or later) in the load module / program object so the table is initialized at the time the program is loaded. Of course, all the entries will be the same. So what was the OP after? An advantage of doing this also allows you to re-initialize the table with the INITIALIZE verb. But, of course, maybe the data the OP wants to put into the table is from an external file or data base. We don't really know. -Steve Comstock On Aug 11, 2014 6:37 PM, Ron Thomas ron5...@gmail.com wrote: Hello. We have a array like this , what would be best way to initlaize this array in terms of performance ? 01 EXAMPLE-TABLE. 05 MY-TABLE. 10 TABLE-ENTRY OCCURS TIMES. 15 FIRST-NAME PIC X(15). 15 LAST-NAME PIC X(15). 15 SEX-CODE PIC X. 15 DOB. 20 DOB- PIC 9(4). 20 DOB-MM PIC 99. 20 DOB-DD PIC 99. 15 SSNPIC 9(9). 15 SALARY PIC S9(9)V99 COMP-3. Thanks Ron T -- 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: INITILAIZE COST
On Mon, Aug 11, 2014 at 8:37 PM, Ron Thomas ron5...@gmail.com wrote: Hello. We have a array like this , what would be best way to initlaize this array in terms of performance ? 01 EXAMPLE-TABLE. 05 MY-TABLE. 10 TABLE-ENTRY OCCURS TIMES. 15 FIRST-NAME PIC X(15). 15 LAST-NAME PIC X(15). 15 SEX-CODE PIC X. 15 DOB. 20 DOB- PIC 9(4). 20 DOB-MM PIC 99. 20 DOB-DD PIC 99. 15 SSNPIC 9(9). 15 SALARY PIC S9(9)V99 COMP-3. Thanks Ron T If you want to initialize it only once, just use the VALUE clause and put it in WORKING-STORAGE. If it is in a subroutine and you want it reinitialized every time the subroutine is CALL'ed, then use a VALUE clause but put it in the LOCAL-STORAGE. WORKING-STORAGE is initialized once per run-unit whereas LOCAL-STORAGE is initialized every time the program is executed (via a CALL). I don't recommend doing the following, but it will probably be the fastest way, assuming you want to initialize it multiple times. 01 EXAMPLE-TABLE. 05 MY-TABLE. 10 TABLE-ENTRY OCCURS TIMES. 15 FIRST-NAME PIC X(15). 15 LAST-NAME PIC X(15). 15 SEX-CODE PIC X. 15 DOB. 20 DOB- PIC 9(4). 20 DOB-MM PIC 99. 20 DOB-DD PIC 99. 15 SSNPIC 9(9). 15 SALARY PIC S9(9)V99 COMP-3. * 01 EXAMPLE-TABLE-I.. 05 MY-TABLE-I. 10 TABLE-ENTRY-I OCCURS TIMES. 15 FIRST-NAME-I PIC X(15) VALUE SPACES. 15 LAST-NAME-I PIC X(15) VALUE SPACES. 15 SEX-CODE -I PIC X VALUE SPACES 15 DOB-I. 20 DOB--I PIC 9(4) VALUE ZERO. 20 DOB-MM-I PIC 99 VALUE ZERO. 20 DOB-DD -IPIC 99 VALUE ZERO. 15 SSN-I PIC 9(9) VALUE ZERO. 15 SALARY-I PIC S9(9)V99 COMP-3. VALUE ZERO. IF LENGTH OF EXAMPLE-TABLE IS NOT EQUAL TO LENGTH OF EXAMPLE-TABLE-I THEN DISPLAY 'PROGRAM DEFINITION ERROR FOR EXAMPLE-TABLE.' UPON SYSOUT DISPLAY 'PROGRAM ABORTING. KILL THE PROGRAMMER!' UPON SYSOUT MOVE +16 TO RETURN-CODE STOP RUN. END-IF MOVE EXAMPLE-TABLE-I TO EXAMPLE-TABLE END-MOVE. Of course, this has many drawbacks. The biggest being that you must keep the EXAMPLE-TABLE and EXAMPLE-TABLE-I in sync. If you don't want this worry, then use the VALUE clause like I showed above. And use the sentence: INITIALIZE EXAMPLE-TABLE to reinitialize the table. From what I have read, this is not CPU efficient. I don't know why. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MASPEGH? (was new JVM based language)
On Mon, 11 Aug 2014 21:34:13 -0500, Paul Gilmartin wrote: I decided I was sated with esoteric languages when I stumbled upon (but never attempted to master) (NSFW?): lol - would you be surprised to learn there is a similarly named scheduler for Linux. The author got a little peeved with the treatment he received on the kernel mailing list ... :o) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
