Re: STCBSST bit of STCBFLG1 of STCB DSECT
Justin R. Bendich wrote: 10. Invoke XDC via its SVC HOOK. Walt Farrell wrote: but have you considered the possibility that step 10 takes you out of subspace mode until you return from the SVC? I write: I know it's not clear from the posts, but... XDC does not run within an SVC. The SVC, when reached by execution, establishes a caller-owned ESTAE with XDC as the exit routine. It (the SVC) then sets a trap (an X'00' opcode which will cause an 0C1) at the caller's resume address. Finally, the SVC terminates back to the caller (the user code) so that the trap get's immediately executed. So the environment within which XDC runs is a simple ESTAE environment for the code being debugged. The SVC is long gone. But what effect this might have on the STCBSST flag, I do not know. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
The care and feeding of dongles (was: Progress Toward z/OS Personal Use License)
Dongles certainly can be fragile, and longer ones, such as the z/PDT's (around 2 inches or so) can easily be accidentally torqued and broken (or break the socket, whatever). For that reason, I keep a supply of 6 long M/F USB cables which I use to separate the dongle from the PC chassis. That solves both the bump-it-and-break-it problem as well as damage from constant removal-and-reinsert. Dongles are valuable. 6 USB cables are cheap. Just saying... Dave Cole At 4/25/2012 11:43 AM, Joel C. Ewing wrote: A dongle definitely could be an issue for some. Might be less of an issue on Linux, but my experiences on Windoze has been less than ideal and makes me regard any application that requires a dongle as more of a gamble. While the dongle may be regarded as nice license insurance from the software vendors standpoint, it is essentially just another point of failure for the user and lowers the value of the product. My wife has some very expensive Embroidery software that requires a dongle. The license does entitle her to run the software on multiple platforms, both her laptop and desktop, since the dongle prevents concurrent use. After a year or so the dongle case became too loose to remove the dongle from the USB port - the only way now is grasp and pull the dongle base with a pair of needle-nose pliers, which works, but is certainly not the advertised convenience. The only support provided by the application vendor to remedy this situation is to re-purchase the software at full price to get a new dongle. Other than using standard Windows GUI interfaces, this software does nothing that special at the Operating System level, except for the dongle support that requires a hardware driver written by yet a different vendor. Logic would suggest that this application should be able to migrate from Win XP to Win 7 without a problem, provided one can find support for the dongle on Win 7. My initial attempts to migrate have so far failed because the dongle vendor's current drivers for Win 7 are not compatible with the older version dongle that came with the application. I haven't given up, but unless I can locate a compatible driver that is also compatible with Win 7 this expensive application is toast on Win 7. A nice result for the application vendor if I'm forced to do an otherwise unnecessary upgrade at great cost, but from the user's standpoint this is a very poor outcome, apparently forced by the decision to require a dongle. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Where to find out about PER zero-address detection?
At 4/25/2012 11:19 AM, Bill Fairchild wrote: When all else fails, try Google. [...] Next I would suggest you Google and/or search IBM books for PER-ZAD. Bill Fairchild Programmer Rocket Software ZAD = Zombie Awareness Day (See http://www.urbandictionary.com/define.php?term=zadhttp://www.urbandictionary.com/define.php?term=zad) [;)] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Malicious Software Protection
At 3/27/2012 04:06 PM, Joel C. Ewing wrote: The concept of allowing average-Joe user to be able to download data from arbitrary sources in arbitrary formats and being able from that to somehow introduce executable code into the system in ways that will execute with special privileges so as to introduce a virus or trojan is an issue that is endemic to Windows platforms but foreign to z/OS. Hmmm, excellent point! I guess part of the problem with Windows systems is that there are so many file types that in one way or another are executables, including many file type that you do not expect to be executable! Example: I was blown away when I learned only a few years ago that .PDFs could be an executable! Who knew? Not me. But the Chinese did... (It was interesting to see the flurry of fixes that Adobe published over the two years or so following the attack against Google...) Not only are so many file types executable, they often are executed by default! So it is a lot easier to let something maliscious slip in on a Windows system than it is on a mainframe. On mainframes files generally do not get executed by default. It generally takes an intentional and direct act to run a program. So worrying about random files upload to the mainframe is an unnecessary distraction. Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Malicious Software Protection
At 3/27/2012 11:19 AM, Pinnacle wrote: There is a mainframe product that protects against malicious software. It's called SAF, and it interfaces with ESM's like RACF, or ACF2, or TopSecret. SAF is not a product. It stands for System Access Facility and it is nothing more than an interface within z/OS into which a security system (such as ACF2, TopSecret and any ryo security system) can plug into to receive and respond to security calls. It really has nothing to do with anti-virus protection. For more information, see http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsecurity/zsecc_030.htmhttp://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsecurity/zsecc_030.htm It [z/OS] is the only operating system out there with built-in anti-virus protection. On top of that, the hardware itself actively protects against damage through storage keys, protected memory, etc. You have to explain to the auditors that anti-virus software is not needed on z/OS, because it's intrinsic to the operating system and the hardware. I think you seriously misunderstand what a virus is... Yes, z/OS has exceptional security (and integrity and reliability) features for protecting against non-authorized programs. But I must emphasize... --NON--authorized programs! When it comes to AUTHORIZED programs, z/OS's integrity (which is what you are talking about with storage keys and such) is very good, but of course not bulletproof. Worse though, when it comes to SECURITY, there are some real problems! Because with the proper knowledge, it is TRIVIALLY EASY FOR AN AUTHORIZED PROGRAM TO SUBVERT SECURITY COMPLETELY! This is what mainframers constantly forget regarding security. For authorized programs there is no security. All that is necessary for a malicious program to do is to Trojan-horse its way (with the AC(1) attribute) into an authorized library, and you're done for! This is something I've brought up on this listserv from time to time before. In particular, for more information, please read a prior post of mine at https://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457I=-3X=6EB01556E36E4D9CACY=dbcole%40colesoft.comd=No+Match%3BMatch%3BMatcheshttps://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457I=-3X=6EB01556E36E4D9CACY=dbcole%40colesoft.comd=No+Match%3BMatch%3BMatches . And please... stop confusing security with integrity. They are not the same. The hardware protections that so many people mention are not security protections, they are integrity protections. They help to keep careless programs from accidentally breaking things. When it comes to authorized programs, these hardware protections offer no protection at all! As far as I know there is no serious anti-virus program for mainframes. I believe strongly that there needs to be one, but I don't know of one. And at this stage of the mainframe culture, I would be seriously suspicious of the efficacy of any program that claimed to be anti-virus. I don't think that a serious mainframe anti-virus program can exist unless and until IBM itself makes a commitment to support an effort to make the mainframe anti-virus proof. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Malicious Software Protection
I'm sorry Tom. I did not intend my remarks to be personal. I deeply regret that you feel hurt by them. Please don't let my words deter you from future contributions. Your thoughts generally are more valuable than most. I just wanted to emphasize the APF Trojan horse vulnerability. It is real, it is serious, yet for decades everyone seems to want to pretend that it does not exist... It mystifies me. www.zassure.com is the closest thing I've seen to an MVS anti-virus program. After seeing a demo, I would have bought it, or recommended it to a client. Check it out, you will be surprised, if not shocked. Thank you for this. I will check it out. [Regarding SAF] I do take issue with your last sentence. SAF and an ESM have everything to do with anti-virus protection, provided they are configured to correctly protect APF-authorized resources. Perhaps. However, all an APF authorized program has to do is flip a bit or two in certain RACF control blocks, and voilà! He's suddenly a supervisory program and, as such, is given a pass on all RACF calls... Alternatively, a malicious APF program can simply dynamically front-end certain supervisory programs, and again voilà! (As I'm sure you know, APF programs can fairly easily defeat all hardware storage protections.) Yes, SAF is still called even for APF programs, but an APF program can still subvert those calls. I've never forgotten this [APF libraries]. That's why my APF-authorized libraries are severely limited in scope, and audited for any and all updates. Enforcing trust is a technical issue. RACF is very good at that. Deciding who to trust is a management issue. Even at shops that allow only trusted vendor software into APF authorized libraries is implicitly trusting the hundreds or even thousands of people involved in the development of that software. Again, I go into more detail about this in my prior post: https://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457I=-3X=6EB01556E36E4D9CACY=dbcole%40colesoft.comd=No+Match%3BMatch%3BMatcheshttps://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457I=-3X=6EB01556E36E4D9CACY=dbcole%40colesoft.comd=No+Match%3BMatch%3BMatches . Again, please accept my apology, Tom. It was not intended to be personal. I'm sorry it came out that way. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 3/27/2012 02:21 PM, Pinnacle wrote: Replies like this are why I seldom post to IBM-Main anymore. The fact that it comes from someone who I respect and consider a friend hurts all the more. Bottom line is that I work for a living, and I often don't have time to respond in gory detail to everything posted. My primary objective here was to stress that the z/OS architecture is inherently hardened against viruses. The fact that I did not go into explicit protections for APF-authorized programs appears to have been my fatal flaw, according to Mr. Cole. Regardless of what comes back, this will be my last post on the subject. My comments below. Regards, Tom Conley On 3/27/2012 1:06 PM, David Cole wrote: At 3/27/2012 11:19 AM, Pinnacle wrote: There is a mainframe product that protects against malicious software. It's called SAF, and it interfaces with ESM's like RACF, or ACF2, or TopSecret. SAF is not a product. It stands for System Access Facility and it is nothing more than an interface within z/OS into which a security system (such as ACF2, TopSecret and any ryo security system) can plug into to receive and respond to security calls. It really has nothing to do with anti-virus protection. SAF is not a product, you're right. Please forgive my use of the term product, I should have said feature. I do take issue with your last sentence. SAF and an ESM have everything to do with anti-virus protection, provided they are configured to correctly protect APF-authorized resources. It [z/OS] is the only operating system out there with built-in anti-virus protection. On top of that, the hardware itself actively protects against damage through storage keys, protected memory, etc. You have to explain to the auditors that anti-virus software is not needed on z/OS, because it's intrinsic to the operating system and the hardware. I think you seriously misunderstand what a virus is... Yes, z/OS has exceptional security (and integrity and reliability) features for protecting against non-authorized programs. But I must emphasize... --NON--authorized programs! When it comes to AUTHORIZED programs, z/OS's integrity (which is what you are talking about with storage keys and such) is very good, but of course not bulletproof. Worse though, when it comes to SECURITY, there are some real problems! Because with the proper knowledge, it is TRIVIALLY EASY FOR AN AUTHORIZED
Re: Secret Service Guide
Wow, that's pretty limited. Sorry it didn't work out. Dave At 3/16/2012 06:08 PM, Farley, Peter x23353 wrote: The wayback machine only has 147 IBM pages, all from 2010, with the link address that appears on the header pages but has no similar IBM pages before that, and nothing at all for the four manual numbers that the OP listed. But thanks for the suggestion. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Cole Sent: Friday, March 16, 2012 4:31 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service Guide You might try www.archive.org. At 3/16/2012 03:41 PM, Farley, Peter x23353 wrote: I did just that in addition to searching within the IBM websites (but I have no access to ResourceLink). Google finds header pages for each of these documents on the IBM websites, but all the links to actually download the manuals are either gone (404) or circular. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Cole Sent: Friday, March 16, 2012 3:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service Guide Have you tried just Googling the manual numbers? At 3/16/2012 10:45 AM, R.S. wrote: W dniu 2012-03-16 14:44, Zaromil Tisler pisze: Service Guide, IBM System z10 Enterprise Class (GC28-6866-05) http://www-01.ibm.com/support/docview.wss?uid=pub1gc28686605 Thank you, I appreciate it. I just downloaded it. I also found doc number for older machines: z9 EC Service Guide GC28-6841 z9 BC Service Guide GC28-6853 z990 Service Guide G229-9039 z900 Service Guide G229-9027 I also found z9EC Service Guide in hardcopy (still looking for sofcopy). So, I'm still looking for Guides for z990, z900 and maybe older machines. I also revealed that the publications usually were delivered on CD/DVD with the CPC. Regards -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Secret Service Guide
Have you tried just Googling the manual numbers? At 3/16/2012 10:45 AM, R.S. wrote: W dniu 2012-03-16 14:44, Zaromil Tisler pisze: Service Guide, IBM System z10 Enterprise Class (GC28-6866-05) http://www-01.ibm.com/support/docview.wss?uid=pub1gc28686605 Thank you, I appreciate it. I just downloaded it. I also found doc number for older machines: z9 EC Service Guide GC28-6841 z9 BC Service Guide GC28-6853 z990 Service Guide G229-9039 z900 Service Guide G229-9027 I also found z9EC Service Guide in hardcopy (still looking for sofcopy). So, I'm still looking for Guides for z990, z900 and maybe older machines. I also revealed that the publications usually were delivered on CD/DVD with the CPC. Regards -- Radoslaw Skorupka Lodz, Poland -- Tretej wiadomoci moe zawierainformacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorcmoe byjedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jesteadresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe bykaralne. Jeeli otrzymaetwiadomoomykowo, prosimy niezwocznie zawiadominadawcwysyajc odpowiedoraz trwale usuntwiadomowczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII WydziaGospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie01.01.2012 r. kapitazakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Secret Service Guide
You might try www.archive.org. At 3/16/2012 03:41 PM, Farley, Peter x23353 wrote: I did just that in addition to searching within the IBM websites (but I have no access to ResourceLink). Google finds header pages for each of these documents on the IBM websites, but all the links to actually download the manuals are either gone (404) or circular. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Cole Sent: Friday, March 16, 2012 3:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service Guide Have you tried just Googling the manual numbers? At 3/16/2012 10:45 AM, R.S. wrote: W dniu 2012-03-16 14:44, Zaromil Tisler pisze: Service Guide, IBM System z10 Enterprise Class (GC28-6866-05) http://www-01.ibm.com/support/docview.wss?uid=pub1gc28686605 Thank you, I appreciate it. I just downloaded it. I also found doc number for older machines: z9 EC Service Guide GC28-6841 z9 BC Service Guide GC28-6853 z990 Service Guide G229-9039 z900 Service Guide G229-9027 I also found z9EC Service Guide in hardcopy (still looking for sofcopy). So, I'm still looking for Guides for z990, z900 and maybe older machines. I also revealed that the publications usually were delivered on CD/DVD with the CPC. Regards -- Radoslaw Skorupka Lodz, Poland -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
John Gilmore wrote: even though, as I believe, the the offender's code itself commits no substantive offense it it is, I think, guilty of the admittedly much subtler offense of providing a template for others, who are bent on mischief, to use. If the PFLIH hook is (as it has been described earlier in these threads) a mechanism by which a non-authorized process can become authorized, then its very existence is a substantive offense in and of itself. It is not just a template, it doesn't just show the way. It *is* the way. I fervently hope that the existence of this thread has gotten the attention of the ISV who has created this obscenity and that it will commit immediate resources to purging this from its products. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 3/1/2012 04:54 PM, John Gilmore wrote: I don't want to put words in EJ's mouth; but if 'an exposure' were replaced by what I should call 'misuse' what he said is correct and not even controversial. I think there is an exposure, in the sense that this device lends itself very readily to abuse. I have seen no evidence that it has actually been misused in any but the tenuous sense that it adds clandestine overhead to the processing of every interrupt. The device itself has been much misused elsewhere. A number of viruses have, for example, used a Windows scheduled task---PC Health Data Collection is a favorite---to hijack PCs. Moreover, now that its use has been publicized here, the scheme it embodies---not, a fortiori, the offender's code itself---is all but certain to be used irresponsibly by others; even though, as I believe, the the offender's code itself commits no substantive offense it it is, I think, guilty of the admittedly much subtler offense of providing a template for others, who are bent on mischief, to use. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
At 3/1/2012 06:46 PM, Skip Robinson wrote: For years we ran a 'channel extender' product call RDS. It worked by front-endng FLIH for I/O interrupts to determine whether the I/O was to or from a supported device as defined to RDS. If not, the I/O was passed along for normal processing. If so, RDS redirected the I/O to its own network device for transmission (out); or written to the intended device (in). It sounds kludgy, but it worked amazingly well. The vendor was very forthright about the internals. We had occasional hardware problems with RDS, but I never once saw an OS failure caused by this technique. This sort of thing is best not done at home. This also is a example of a legitimate use of an intercept. It does not confer authority upon its caller. All it does is perform a service on behalf of a caller and which the caller itself does not have the authority to perform on its own. In this sense it is no different from any other system service (OPEN, WTO, GETMAIN, etc.) performed by the OS. JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
At 3/2/2012 10:25 AM, Edward Jaffe wrote: On 3/2/2012 1:29 AM, David Cole wrote: If the PFLIH hook is (as it has been described earlier in these threads) a mechanism by which a non-authorized process can become authorized, then its very existence is a substantive offense in and of itself. It is not just a template, it doesn't just show the way. It *is* the way. I keep coming back to IGX00011. It's presence on z/OS systems PROVES that the very existence of a magic SVC service, while arguably not a 21st-century best practice, is NOT considered an exposure or substantive offense when done correctly. (Those last three words are very important!) A magic PFLIH technique is not substantially different, from an integrity standpoint, than a magic SVC except that the code gets control for EVERY interrupt and so has the potential to slow things down if not implemented efficiently. The real question is whether an unintended third party can use the code to become authorized. Yes. That absolutely is the real question. And absolutely, that is what Bill Fairchild's post asserts. So that absolutely is why I am concerned. Unlike the magic SVCs of the past, I'm confident that IGX00011 cannot be exploited by unintended third parties. That is good to know. The same might very well be true of the PFLIH approach being discussed here, despite any third-party hearsay from Bill Fairchild's colleague claiming otherwise. Certainly, the hearsay could be wrong. And I do hope that it is wrong. But it is a better course to assume that the charge is right and raise awareness to the point where it will be investigated and PROVEN to be right or wrong... ... than it is to assume that the charge is wrong and just sit back and *hope* that nothing bad happens. In other words, I think that being noisy about this issue will have a more constructive result than being silent will. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Deleting named ISPF edit profiles
Does anyone know if there is a way to delete a no longer needed named ISPF edit profile? TIA Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Deleting named ISPF edit profiles
Well, thank you, John! That was almost exactly the information I needed. With the following adjustments, I was able to get the job done. * It doesn't look like I need to start with ISPF TEST. Just ISPF seems to work just fine. * On my system, the Tables Utility is at =3.16. * Once within the Utility, to get at the EDIT profiles, I needed to provide the ddname ISPPROF. * And on my system the table name is, indeed, ISREDIT. * If I omit the Option and Table Name fields on the ISPF Table Utility page: * I am shown a list of all profile members * I than can issue E on the ISREDIT line to open that table for editing. * This displays a named list of profiles within ISREDIT. * I can then use the D line command to delete the profiles I want to get rid of. So thanks, John, for putting me on the right track. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 3/1/2012 08:18 AM, McKown, John wrote: I'm sure somebody does. Is that your question? grin The edit profiles individual rows in the ISREDIT table. You can manually deleted by using ISPF TEST, option 4 (Tables). But the table is not keyed, so you must search it for the proper row number to delete. Well, I lied a bit (if not 100% complete truth == lie). ISREDIT is the normal table name, but the ISR prefix can be different if the ISPF application is not ISR. Eg, when you edit in SDSF, the prefix is ISF instead of ISR. So the table name is then ISFEDIT. In general, it is abcEDIT where abc can vary. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Cole Sent: Thursday, March 01, 2012 5:57 AM To: IBM-MAIN@bama.ua.edu Subject: Deleting named ISPF edit profiles Does anyone know if there is a way to delete a no longer needed named ISPF edit profile? TIA Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Ed, Let me quote to you what Bill Fairchild posted earlier on this thread: At 2/23/2012 05:42 PM, Bill Fairchild wrote: I found a similar (and maybe the same) vendor hook in 1996, disassembled the code, and discovered that one of its purposes was to put an unauthorized caller into various protect keys, supervisor state, etc., based on the contents of a register. I alerted the vendor that using a hook such as this was not the optimal way to get into some authorized state. Literally anyone could have disassembled the code enough to see how to exploit the hook and get an unauthorized program into supervisor state and key 0. The vendor made some changes shortly thereafter and claimed that the enhancement was now much better. [***===] I didn't have time to disassemble the new version and figure out how to hack into it, but a colleague of mine did and said it was still relatively easy to subvert. [===***] This vendor has many products which are typically installed in a system all at the same time, and many of their products make use of this program FLIH hook to do authorized things. That is the genesis of my very strong reaction to this thread. Certainly hooking xFLIH or SVCs or whatever is not, in and of itself, evil. However, then using said hook to grant your programs authority is where it all goes very very south! As Fairchild's colleague demonstrates, such backdoors generally can be subverted. That fact that we do not know that the code is still subvertable is no excuse for inaction. The threat, as described in this thread, is significant. Doing nothing is just burying one's head in the sand. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 3/1/2012 11:52 AM, Edward Jaffe wrote: On 3/1/2012 6:52 AM, David Cole wrote: This is not just despicable, under today's law, it is actually criminal! Any vendor who does this could be (and should be) jailed in criminal courts and sued out of existence in civil courts. I do not know who is doing this, but I believe utmost pressure must be brought to bear upon that vendor so that it will commit every resource to removing the breach from its products. Just to clear: intercepting the FLIH does not itself constitute an exposure and, as far as state changes go, the checking and requirements could be complete enough to avoid any integrity problem. For example, the methodology could be similar to that employed by IBM's IGX00011 magic SVC and its intended caller. Unless someone can prove there really is an exposure, which to my knowledge has not been done, I suggest that passing such judgment is premature. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Debugging CICS Global User Exits
Hi Mike, I don't know a thing about CICS, but I do know a little about z/XDC. If you can give me detailed information about a Global User Exit's runtime environment, I might be able to help you out. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 1/7/2012 11:12 PM, Micheal Butz wrote: Hi, Would anyone know the best method to debug CICS Global User Exits For MVS I usually used XDC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
z/XDC: Important Maintenance
I have just posted to www.colesoft.com some important maintenance for the z1.13 release of z/XDC. Customers should please download and APPLY it at their earliest convenience. For more information, visit ColeSoft Marketing's Facebook page. Thank you, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing g RTM routine
At 10/28/2011 11:43 AM, Bill Fairchild wrote: After following the advice in all the other previous answers, sooner or later you will still need to know how to test your SRB and its recovery routine. You probably won't be able to instruction-step or trace either very easily with TSOTEST or XDC. FWIW: z/XDC has *explicit* support for testing SRB code that is actually running within SRB environments. This support includes the ability to step through SRBs instruction by instruction, ... and includes the ability to debug locked code! Yes, there are some limitations, but they are less that what you might think, and within those limitations, z/XDC can be unexpectedly useful! Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.xdc.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ABEND0F8-20
Thanks Peter. Your answers are directly on point. I appreciate it. Dave At 10/26/2011 07:48 AM, Peter Relson wrote: Due to a screw-up on our part many of the z/OS 1.13 RMODE 64-related updates to the books did not make it. This was one. While the books themselves might not get updated for some time, there will likely be an info APAR directing you to some web location where you can find all the missing information. That is not in place yet. I can confirm that ABEND0F8-20 is indeed you issued an SVC other than SVC X'D' (ABEND) from code that resides = 2G Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ABEND0F8-20
Does anyone know what an abend s0F8-20 means? Code 20 is not documented even in R1.13's MVS System Codes manual. I suspect it means that you cannot issue an SVC instruction from above the bar. Can anyone confirm or deny that? Thanks, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/XDC z1.13 is now Generally Available
z/XDC release z1.13 has finally been published! It supports z/OS R1.13 and the debugging of code located above the bar. More information can be found at our Facebook page. When on Facebook, just search for Colesoft Marketing, and then like us. A press release can be found at http://www.colesoft.com/PressRelease/111014_z113release.htmlhttp://www.colesoft.com/PressRelease/111014_z113release.html. Thank You. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
TCBFX vs. TCBNOIRB
Can anyone tell me the difference in purpose or management between the TCBFX flag and the TCBNOIRB flag? As far as I know they both are supposed to prevent the queuing of IRBs. In the IKJTCB macro they each are doc'd as follows: TCBNOIRB EQU X'40' - If on, IRBs will not be queued to this TCB. @08A * A program setting this flag MUST save its * current value and restore that value either * when that program can tolerate IRBs being * queued or before the current RB terminates. TCBFXEQU X'01' - PROHIBIT QUEUEING OF ASYNCHRONOUS EXITS FOR * THIS TASK So why do they both exist? Thanks, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Who uses RBGRSAVE in a task's *oldest* RB?
Here's an interesting question... Given that when a task is interrupted: (1) It's registers (Rn, RHn and ARn) are saved in the TCB and STCB (2) When the interrupt (such as SVCs or program checks or certain asynchronous ones) leads to the creation of a new RB, those saved registers are eventually copied into the *newly created* RB and XSB ... it would seem that the RBGRSAVE, XSBARS and XSBG64H fields for the *oldest* RB and XSB would remain forever unused. HOWEVER, I ran a test. From an instance of an authorized XDC running under a newer RB, I manually zapped the contents of the *oldest* RBGRSAVE to garbage values to see what would happen when said oldest RB (two RBs removed from XDC's RB) was later resumed. To my surprise, trouble did not wait. My aspace crashed instantly! (s333-20). So somebody's using that oldest RBGRSAVE in an unexpected way. I'm just wondering if anybody knows who... Thanks, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCBFX vs. TCBNOIRB
Hi Jim, Thanks for taking a stab at this. I've looked at the APARs you suggested, but if the offer clues to my question, I'm not seeing them... As far as I know, TCBFX and TCBNOIRB both serve the same function: When either is on, the queuing of IRBs to the task is deferred. Both of the APARs you suggested, discuss problems when such deferrals are not managed properly. What I want to know is, why the redundancy? Why are there two flags that serve the same purpose? There must be subtle differences... What are they? What am I missing? Thanks, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 9/30/2011 02:04 PM, Jim Thomas wrote: Sir, For TCBNOIRB, I'd suggest scanning thru an old APAR (OA19796) and perhaps following on to some of the other related APAR's (please keep in mind, 'IRB'). For TCBFX, I'd suggest, OA16342 and related (please keep in mind, 'asynchronous'). From the little I've used these flags, it's more a question of whom the 'setter/reset r' is and obviously, what is being done. Kind Regards Jim Thomas 617-233-4130 (mobile) 636-294-1014(res) j...@thethomasresidence.us (Email) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Cole Sent: Friday, September 30, 2011 5:01 AM To: IBM-MAIN@bama.ua.edu Subject: TCBFX vs. TCBNOIRB Can anyone tell me the difference in purpose or management between the TCBFX flag and the TCBNOIRB flag? As far as I know they both are supposed to prevent the queuing of IRBs. In the IKJTCB macro they each are doc'd as follows: TCBNOIRB EQU X'40' - If on, IRBs will not be queued to this TCB. * A program setting this flag MUST save its * current value and restore that value either * when that program can tolerate IRBs being * queued or before the current RB terminates. TCBFXEQU X'01' - PROHIBIT QUEUEING OF ASYNCHRONOUS EXITS FOR * THIS TASK So why do they both exist? Thanks, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCBFX vs. TCBNOIRB
Ok, that's a policy difference and is good to know. Thanks. I'd still like to know what the functional difference is (if any). Thanks, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 9/30/2011 02:50 PM, Tom Harper wrote: David, I believe that TCBNOIRB is within TCBFLGS8 which is part of the programming interface whereas TCBFX is within TCBFLGS1 which is not. Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCBFX vs. TCBNOIRB
Interesting... How old is your Stage 3 exit Effector Logic manual? (I'm guessing at least a couple of decades.) I *think* that the TCBNOIRB flag might be newer than your manual. I don't know when it was introduced, but I became aware of TCBNOIRB only within the past year. The TCBFX flag I've known about for several decades. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 9/30/2011 04:01 PM, Faye Huang wrote: Is it possible that TCBFX is used to suppress the scheduling of all asynchronous exit for a task, whereas TCBNOIRB specifically suppresses IRBs but not SIRBs. Stage 3 exit effector logic manual indicates TCBFX=1 prevents all asynchrounous scheduling to the task but has no mention of TCBINOIRB. Thanks, Raymond Wong -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCBFX vs. TCBNOIRB
At 9/30/2011 04:12 PM, Jim Thomas wrote: The focus is not on IRB's but mainly, the ability to use SRB's .. (this is where I tried to point out IRB vs SRB .. IOW ... with TCBNOIRB ... you can still ... IIRC, use SRB's). SRBs? or SIRBs? I would be surprised if a TCB setting such as TCBFX would have any affect at all on SRBs. But I think maybe Faye Huang maybe has something when she said: ...whereas TCBNOIRB specifically suppresses IRBs but not SIRBs. I actually don't know anything about System Interrupt Request Blocks (SIRBs). I know that they exist, but I don't know what they're used for. Can anyone enlighten me on this issue as well? If you'd like to go into detail .. perhaps explain what you're trying to do and such ... please feel free to contact / email me .. (after the weekend though please) directly and please understand that my current access to MVS (or z/OS or whatever the hell you want to call it) is rather limited so my responses might be slooow Thanks for the offer. At the moment, though, I'm just researching. Kind Regards Jim Thomas 617-233-4130 (mobile) 636-294-1014(res) j...@thethomasresidence.us (Email) Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCBFX vs. TCBNOIRB
That puts it at z/OS R1.5 At 9/30/2011 04:36 PM, Jim Mulder wrote: Wow, it actually dated back 1981, 1983. I do not even realize TCBNOIRB didn't exist then. Do you know what z/OS version it was introduced? Use the source, Luke. I don't always think to look in MACLIB... Would that I had your level of access to the source, Jim. Can you shed any link on my TCBFX vs TCBNOIRB question? Dave BROWSESYS1.MACLIB(IKJTCB)Li Command === .* $08=OW47908 HBB6605 010129 U2IAXZ: Add TCBNOIRB Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCBFX vs. TCBNOIRB
Thanks for the link, Jim. I'll take a look. Dave At 9/30/2011 04:41 PM, Jim Thomas wrote: Sir, Try this ... I think (like Ray) that I have the same manual ... http://www.bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/plm/GY28-6616-9_OS_IO_Su perv_PLM_R21.7_Apr73.pdf and yes ... it is old ... but for the most part, still very much valid (that I know of). Kind Regards Jim Thomas 617-233-4130 (mobile) 636-294-1014(res) j...@thethomasresidence.us (Email) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/XDC release z1.13
Sometime in September (guess when), we will be publishing release z1.13 of z/XDC. There is more information at our Facebook page. To access it, get onto Facebook, search for ColeSoft Marketing and Like (i.e. opt in to) our page there. Thanks, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.xdc.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/XDC release z1.12 is NOT! supported in z/OS R1.13 Systems (repost)
[Damn! I'm constantly forgetting that these lists don't like HTML formatted posts... sigh] Because of some changes that IBM has made in z/OS R1.13, there is a potential for System corruption when older releases of z/XDC (z1.12 and older) are run in z/OS R1.13. I want to emphasize that it is not(!) likely that other z/OS software will have the same issues that z/XDC does. I also want to emphasize that these issues have been corrected in our z1.13 release of z/XDC, and that z1.13 will be made available both when z/OS R1.13 is G.A.'d and to anyone else amongst our customers who is running a pre-release version of z/OS R1.13. I also want to emphasize that the problems that z1.12 and older releases of z/XDC have in z/OS R1.13 are intermittent and can be hidden and can be remote from z/XDC. Accordingly, we will not support the running release z1.12 (and older) of z/XDC in z/OS R1.13, and recently we have even gone so far as to post maintenance for z1.12 that, once applied, will prevent z1.12 from even running within z/OS R1.13. If you are currently running z/OS R1.13 and also running z/XDC z1.12 (or older), please immediately contact us privately so that we may send you our beta of z1.13. Thank You, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 8/30/2011 10:54 AM, David Cole wrote: The best I can say, Ed, is that I find that surprising. More privately. Dave At 8/30/2011 10:22 AM, Edward Jaffe wrote: On 8/30/2011 4:25 AM, David Cole wrote: Sometime in September (guess when), we will be publishing release z1.13 of z/XDC. There is more information at our Facebook page. To access it, get onto Facebook, search for ColeSoft Marketing and Like (i.e. opt in to) our page there. We have been using z/XDC z1.12 under z/OS 1.13 since January without any obvious problems. I guess we've just been lucky. Either that or we're not very sophisticated users. ;-) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HLASM Manuals
John, Thanks for asking... How to improve the Assembler manuals? Well, one thing that comes leaping to mind: WRT the Reference, I would really love it if you would put individual build-in functions in the TOC. You do this for Assembler statements and even system variables... Why not for built-in functions as well. (This is something that has irked me for DECADES!) But more than that... Over all I think the Assembler Reference is very poorly organized. It is hard to find things within. It is hard to understand the implications of described functionality. The descriptions are laconic (to say the least), and the examples are classically awful. They cover only the fewest and the simplest, most obvious cases; they fail to illustrate useful ranges of capabilities. I love Assembler. I've been programming in it for nearly 50 years. I cannot say the same for the Reference. In the entire time I've been programming Assembler, the organization and structure of the Reference has not changed one iota! Yes, new functionality has been added, but I don't think that more than a handful of words of the original text has been changed since the 1960s! IMO, the Reference basically needs to be thrown out and rewritten from scratch with totally fresh eyes. And it needs to be usability tested along the way by an audience of people who do not already know the language inside and out (or by those who can at least think that way). I hear all the time that Assembler is hard. It is not hard. C is hard; Assembler is easy. It's just the manual that is hard. I also hear grumbles that IBM manuals in general are hard. I do not agree. Many of them have improved quite a lot in recent decades. But not the Assembler Reference. It remains mired in its initial design, and for whatever reason, it has escaped a competent rewrite. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 8/18/2011 07:00 PM, John Ehrman wrote: On June 6, John Walker noted that IBM manuals don't make it easy to find information you need. If you have suggestions for improving the HLASM manuals, please let me know, either on or off this list. Thanks for your help. John Ehrman, ehr...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Opening up Boulder Doc to user comments??? (was a new POP)
There is a germ of an interesting idea here... What about IBM changing the Boulder online doc (http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsphttp://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp) to permit moderated annotations/commentary arising from user experience??? Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 8/19/2011 02:00 PM, Kirk Talman wrote: the root cause of most complaints about any form of documentation today is that we have been spoiled by search engines and that we have a lot less time to do what is right over what is expedient. the method I have been trying to sell on my job is use wikis as connective tissue to hold and make effective the flesh and bones of other documentation formats. the response has been blank looks, sneers and ugly words. The community that consists of the members of this list could just build the future by making a site which represents their cumulative knowledge. It would require managed access to fend off trolls. Example: IBM has a nice site for a glossary for terms. But because it represents knowledge gathered from across the enterprise, it appears to be less than current and has omissions. If wikimedia software (or the equivalent) were made to have a separate permission list for each namespace,, and if automatic disambiguation were implemented, the contributions of disparate groups could seamlessly (or almost so) be merged into one knowledgebase - completely w/o a donnybrook over who is right about, oh, say, USS. pup Our greatest danger in life is in permitting the urgent things to crowd out the important. - Charles E. Hummel Efforts and courage are not enough without purpose and direction. - John F. Kennedy IBM Mainframe Assembler List assembler-l...@listserv.uga.edu wrote on 08/19/2011 01:14:25 PM: From: Steve Comstock st...@trainersfriend.com To: assembler-l...@listserv.uga.edu Date: 08/19/2011 01:16 PM Subject: Re: a new POP (was HLASM Manuals ) Sent by: IBM Mainframe Assembler List assembler-l...@listserv.uga.edu On 8/19/2011 10:55 AM, Martin Trübner wrote: While I am happy with the L.R. I like to comment on Kens' The assembler manual I would like to see rewritten is the Principles of Opeertations Absolutly while POP (the way it is) may have its place- I have a hard time reading about a certain instruction (when I need to). It is IMHO more than counterproductive (I dare to say confusing) for the reader (but time saving for the authors of the hardware/micro-code) to have identical instructions with only variations in a-mode and/ or targets in one paragraph- this results in very subtle changes in the wording for the various flavours. I would prefer (even if this would create a manual three times as big) every instruction in a separate text. For illustration look at TRxx (xx=OT/OO/TT/TO) - or (for a simpler sample) look at AH/AHY/AH/AGHI. It would make life easier for everyone using this book if each of these instructions would be explained in a different chapter. The way it is now is that the reader is challenged to read all the fine print. To me it means reading the instructions at least twice (if not more). (and all the AH is explained in different text. It is an inherently complex topic. It takes work to 'get it'. And even then, subtleties are easily missed. Who on this list has not written an Assembler program and then five years (or even six months) later wondered how they could write this crap? :-) It takes practice and experience. I'm not sure the authors can do much better without skimming over points that come back to bite the unsuspecting programmer later. Of course, a class can help speed the process. :-) -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * Special promotion: 15% off on all DB2 training classes scheduled by September 1, taught by year end 2011 * Check out our entire DB2 curriculum at: http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this
Re: Lines, Bars and ... mini-bars???
At 7/10/2011 03:47 PM, Justin R. Bendich wrote: I agree with Scott and Walter that it must be above the bar if it's not addressable in AMODE 31. Understand that that's below GAGALAND, but, yeah, i guess you need another name. What?? That didn't catch on either -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Lines, Bars and ... mini-bars???
So... what exactly is the bar? There seems to be some disagreement. And that's natural since, being technology developers, we make up our nomenclature as we go along, so variations in nuances (nuancai?) can easily arise... To some, the bar is the 2G line... At 7/5/2011 11:00 AM, Tom Marchant wrote: I think that above the bar means 2G. It is true that the bar was once described as having a thickness of 2G as IARV64 would not create a memory object in that area. I think that is now obsolete. At 7/5/2011 11:49 AM, John McKown wrote: z/OS hurls if the PSW instruction address is above the bar. [[[... That would be any address =2G, so I guess John holds to the 2G line view. -dbc]]] At 7/5/2011 11:51 AM, Cheryl Walker wrote: Above the bar 2G. At 7/5/2011 01:10 PM, Bill Fairchild wrote: Regardless of other restrictions that IBM may add to the use of storage above the bar, the bar is still the virtual address 2GB. And to many, the bar is the very thick 2G to 4G area... At 7/5/2011 08:11 AM, Gene Hudders wrote: Isn't the reason it is called a Bar is because it is 2 GB in size and not a simple 1 byte from 16 MB to 16+1 MB? [[[... I think that reasin it's called a bar is simply becuase it is a word that is different from line -dbc]]] At 7/5/2011 09:07 AM, Mark Zelden wrote: Since the bar is 2G thick (or it used to be before Java started to use it), maybe it can be called in the bar. At 7/5/2011 09:34 AM, Mohammad Khan wrote: Since bars unlike lines do have some thickness I like to think of the bar being the range from 2G - 4G but that's just me. [[[... No, apparently it's not just you. -dbc]]] At 7/5/2011 11:32 AM, John McKown wrote: Java uses memory in the bar? An IBMer stated that is impossible. [[[... It used to be impossible -dbc]]] At 7/5/2011 12:02 PM, Paul Gilmartin wrote: I vote for within the bar. At 7/5/2011 07:43 PM, Gibney, Dave wrote: I've never had a problem considering it within the bar. I always thought of the bar as being 2G thick as opposed to the 2 dimensional line. At 7/6/2011 06:46 AM, Jan MOEYERSONS wrote: It's called the bar. The bar being 2GB thick. And some have followed their own road altogether... [;)] At 7/5/2011 01:10 PM, Bill Fairchild wrote: [...] above the 2G proto-bar but possibly below the 4G quasi-bar, or even up to the 32G neo-bar. [[[... Well actually Bill goes on to state that he believes the bar is the 2G line. But I do like his creativity here. [;)] -dbc]]] And to still others, the bar is the 4G line. That's my own view, and the view of ... Oh-oh! Apparently no others? Woh! Am I really going to have to change my whole world view here? Or could I stick to my guns and bring all you other misguided souls around to my self-evidently correct view? [Sorta like the Casey Anthony jury, right?] Are there any supporters out there of the 4G view? Just wondering... Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Lines, Bars and ... mini-bars???
So I'm working on XDC adding support for debugging execution above the bar, when I run into a nomenclature problem... Above the line means 16M. Above the bar means 4G. But AMODE(31) supports execution in only the zero to 2G range. For the 2G to 4G range, you need AMODE(64). So what is the name for the 2G to 4G range of storage? Ok, you guys can go ahead and fight it out. Me? I'm just going to call it above the mini bar. [;)] Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Lines, Bars and ... mini-bars???
At 7/5/2011 12:02 PM, Paul Gilmartin wrote: Again, not the hardware, but a construct of z/OS which scrunches the PSW to 64 bits, discarding the upper 32 bits of the program address. LPSW loads scrunched PSWs... LPSW is sorta in the hardware, isn't it? Just saying... Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Lines, Bars and ... mini-bars???
Hi Bruno, It seems useful to me to have a distinct shorthand way to refer to the 2G line vs. the 4G line. Since bar already refers to the 4G line, using mini-bar to refer to the 2G line appeals to me. As regards to a name for the 2G-4G area, DEADZONE is something I came up with back in 2004 for use by z/XDC. But now the dead zone isn't so dead anymore, is it... Since 2G-32G is now reserved for use by JAVA, maybe the JAVAHUTT??? (Jabba_the_Hutt is probably a bit too long.) Dave At 7/5/2011 02:24 AM, Bruno Sugliani wrote: So what is the name for the 2G to 4G range of storage? Ok, you guys can go ahead and fight it out. Me? I'm just going to call it above the mini bar. Kiss principle : Why don't you call it the bar like it should be ? Or are you a toetotaller ? -- Sincères salutations / Best regards Bruno SUGLIANI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DCBs and DCBEs - Could IBM have done it any worse?
Hi Peter, Although I have a lot of disagreement over the original design of silently blowing away the DCBE for one (not disclosed) reason from a list of (disclosed much later) reasons, I can certainly understand not wanting to change that behavior now that it has been released into the wild. However, that does not foreclose all possible solutions. One that occurs to me would be to create a new option (perhaps in the DCB, perhaps the new 31-bit OPEN plist) whereby the developer can explicitly request a more reasonable handling of a bad DCBE error. WRT creating an option flag in the DCB, in regards to signalling the presence of the DCBE, you deftly finessed the no available flag problem by using a 2-bit signal. I bet you can do something like that for this as well. In any case, you know as well as I that downward compatible solutions can be created. I expect at this point the real issue is cost-vs-benefit (ie, resources which is just a synonym for money and commitment). Dave At 6/13/2011 08:44 AM, Peter Relson wrote: IBM very rarely will change an existing RC=0 to some non-0 value. This is for compatibility reasons. Even rarer (if ever) would be to do this in the service stream. We would not want to break some potentially critical application that had a correct program such as OPEN If R15 not-equal 0 then abend When the application had, in effect, wanted the long-standing (somewhat strange) behavior of ignoring the DCBE because of its key (or any of the other reasons why a DCBE might be ignored). Likely? No. Impossible? No. z/OS is full of horrible defaults and behaviors that are legacy behaviors that we don't dare change and instead must make a user overtly request new behavior. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 6/11/2011 01:29 AM, Jim Mulder wrote: The particular documentation to which Ed refers is available only to ISVs who are under nondisclosure. Dave Cole is among those, and thus he should have access to it. For the rest of the IBM-MAIN folks, I will say that it just describes the issue which Dave Cole has very accurately described, and says that it has been resolved in z/OS 1.13. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY Thanks Jim. I, of course, was not free to make that disclosure. I appreciate your doing so for the list's benefit. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 6/10/2011 12:37 AM, Edward Jaffe wrote: This issue, and IBM's resolution intended for a release not yet generally available, was covered at the April 2010 TDM (session 36, pp. 84-85). Ah. You, sir, obviously are far more able to stay awake at those meetings than I. Your cite is exactly on point. THANK YOU! [:)] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DCBs and DCBEs - Could IBM have done it any worse?
rant-on I just shot a bug in z/XDC that occurred only rarely, but once it occurred, it drove me nuts! And frankly, I don't think it's even my fault. It comes from what seems to me (to put it as politely as I can) to be IBM's clear violation of the principle of least surprise... Ok, first of all, here it is around 3 decades(!) after the introduction of 31-bit addressing, and DCBs still must reside in 24-bit storage?? And the best solution to this intransigence is the DCBE??? [sigh...]But I digress. That's a subject for an entirely different rant. rant off nope, rant on and on and on ... What's got me going today is this. For very good reasons, I have created my DCB and DCBE (as well as a host of other data areas and control blocks) in key-9 storage. But my code (z/XDC), when running non-authorized, runs with execution key-8. So when I open my dataset, OPEN does the following: - OPEN services opens the key-9 DCB just fine, no complaints, not a peep. - But when OPEN sees that: - It's caller (z/XDC) is running in problem state, - And it's caller is running in execution key-8, - But the DCBE is in key-9 storage, OPEN zero's out the DCBDCBE field (the DCB's link to the DCBE), and proceeds to open the DCB without the DCBE. Nevermind that key-9 storage is problem program storage. Nevermind that problem state key-8 programs are free to write to key-9 storage no matter what. Nevermind that OPEN has no complaint about the key-9 DCB. Nevermind that neither GET nor PUT nor READ nor WRITE nor CHECK nor FIND have ever complained about the key-9 DCB and DCBE. (How do I know WRT the DCBE? See below...) Nevermind that CLOSE has ever had a problem with the key-9 DCB and DCBE. OPEN simply blows away the DCBDCBE field as if nobody would care... Worse, OPEN gives no notice that it has done this! - OPEN does not abend. - OPEN does not fail to open the dataset. - OPEN does not set any return or reason code. - OPEN does not set any error, warning or informational flag. OPEN just proceeds as if the DCBE simply does not matter... [It's just unbelievable!] So I never noticed this issue until I had a broken file that resulted in s001 abends, which, I knew, couldn't happen... [Boy, I wish I had a dime for every time I've heard that...] So when I investigated, it took me a rather long time to figure it all out. Particularly because I couldn't believe that OPEN would do such a stupid thing! I was, well... surprised! Well, it turns out that there is a pretty simple workaround. Out of desperation, after OPEN completed, all dumb and happy, - I just slammed @'DCBE back into the DCBDCBE field, - And I turned DCBH0 and DCBH1 flags back on, - And voilà, my 31-bit EODAD and SYNAD routines now work just fine. Now, I don't use any of the other advanced services of the DCBE, so I don't know if this kludge would work with respect to those, but as far as I/O errors and end of data are concerned, my code is now happy, so I'm happy too [sort of... at least until IBM decides to fix against my workaround...] But come-on IBM, can't you do better than this rant off I want to thank IBM for the wonderful life they and their software have given me for the past 45+ years! It's things like this that help sell z/XDC [;)] Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 6/8/2011 04:25 PM, Scott Rowe wrote: Dave, I was happy to see that you are only barking: at the hand that feeds you ;-) Have you opened a PMR with IBM on this to see if it is WAD? Well, it's certainly WAC... For reason's I cannot get into, I am unable to open PMRs... Maybe my rant will move someone else to do so. In any case, I've got my workaround, and now you do too... Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 6/8/2011 05:10 PM, Pommier, Rex R. wrote: Dave, But doesn't everything WAC? (I presume you mean Works As Coded). :-) Rex Uh-huh... Way back in the '70s, when a colleague tried to file an APAR (remember what that actually stands for?) over some now forgotten issue, IBM refused to do so, saying It doesn't need 'fixing' because [you guessed it] it works as coded... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems with TSO TEST
At 5/24/2011 02:36 PM, Binyamin Dissen wrote: TEST 'SYS1.LINKLIB(IEFBR14)' TEST L +0 +0 1BFF07FE TEST L +0 I IKJ57245I INVALID INSTRUCTION CODE AT +0 TEST AT +0 IKJ57306I NO BREAKPOINT ESTABLISHED AT +0 + IKJ57306I INVALID OP CODE TEST END Any ideas? Yeah, try z/XDC... (sorry, couldn't resist [;)] ) At 5/26/2011 09:28 AM, Sam Bass wrote: Many years ago IEFBR14 was moved from LINKLIB to LPALIB. You cannot modify modules in LPA, which is what AT command does. You would have to copy IEFBR14 to you own load library and test from there. Sam Bass FWIW, z/XDC can... At 5/26/2011 10:11 AM, Binyamin Dissen wrote: TEST has absolutely no problem testing modules from LPALIB. It loads them into private storage for testing. Ok, for problem mode testing. Seriously problematic for APF authorized testing... z/XDC, when authorized, security permitted and done with suitable case and intelligence, can test PLPA programs running in place... [recommended, of course, only when playing in a sandbox...] Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems with TSO TEST
At 5/29/2011 12:59 PM, David Cole wrote: [snip] z/XDC, when authorized, security permitted and done with suitable case and intelligence, can test PLPA programs running in place... [recommended, of course, only when playing in a sandbox...] Sorry, that should be suitable CARE and intelligence ... [damned typos!] dbc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)
At 5/26/2011 10:32 AM, Ralph Robison wrote: In the context of this debate, you may find it interesting to read IBM Social Computing Guidelines at http://www.ibm.com/blogs/zz/en/guidelines.html Great find, Ralph! Thanks, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)
At 5/23/2011 09:26 PM, Doug wrote: Cole, The 'Rants and Raves' of the list really do show a unique, though somewhat 'mainframe' view. Glad to see you are still hard at it! Let the Good Karma flow and just sit back and enjoy! Doug Thanks for the encouragement Doug. I appreciate it. [:)] At 5/23/2011 10:03 PM, Ted MacNEIL wrote: It's not necessarily phobic. Don't you get it? It's the fact that most of your customers' management have policies in place to block. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL Most? (a) Perhaps. (b) Perhaps not. But Ummm, that's not a fact Ted, that's just a speculation. Some would be a demonstrated fact. And it certainly is a fact that I will have to take into account going forward. As I said, the Facebook presence is an experiment, but so far, it is an experiment that I'm happy with. But the experiment will fizzle if it does not gain wider acceptance, both in the specific case of my own efforts and in the wider audience of our industry in general. But if I had to guess, I'd guess [obviously] that acceptance will broaden. And that already is a fact WRT my own efforts, but only a speculation WRT the industry. [FWIW, the particular Facebook posting of mine in question has garnered 171 impressions since yesterday. I'm quite happy with that...] For those of you who are blocked by company firewalls, I bet that as I and others take to Facebook, you could mount arguments against that blockage. And I bet that some of you could win that argument quickly, and I speculate that most of you could win that argument over the long term. (unless of course your employer is the government... [sigh]) In any case, I'll learn far more by going with b than a. So yes, I think I do get it. At 5/24/2011 07:37 AM, Elardus Engelbrecht wrote: For example, my company blocks gamesites, FB, youtube, twitter and lots of others, but not google, wikipedia and linkedin. This is the normal trend here in sunny South Africa. ;-D Groete / Greetings Elardus Engelbrecht Blocking web categories is about as good an idea as cutting diamonds with sledgehammers would be... Another reason is that your company network must be available as much for their customers for, ahem, cough-cough, work purposes! ... but I see I'm preaching to the choir here. For example, my company blocks [...] FB [...] but not [...] linkedin. Maybe I'll have to reconsider my disdain for LinkedIn... At 5/24/2011 08:34 AM, Thomas David Rivers wrote: It is surprising how direct e-mail no longer works. [snip][snip][snip] Thanks, Dave, for expending the effort to articulate what I was too tired to express. You are absolutely right. People do get tired of having more stuff (email, etc.) pushed to them than they can possibly deal with. In my case, there is a vast(!) amount of information reaching my in-box that I would actually find good, useful and interesting to read. BUT even the valuable stuff overwhelms my ability to deal with it. So a lot of very good stuff (such as well over 99% of IBM-MAIN posts) never gets past the subject line with me. I don't agree that our Facebook page would replace our web site, but I do hope it becomes a very good supplement. And as I said in my very first post to this thread, one attraction Facebook has for us is that it is very easy for customers (not blocked by management) to opt-in and, therefore, receive our push because they want(!) to receive our push. Thanks, Dave, for your encouragement. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)
Please add a third question to your poll... LinkedIn Specifically? Thanks At 5/24/2011 01:41 PM, Ted MacNEIL wrote: Most? (a) Perhaps. (b) Perhaps not. But Ummm, that's not a fact Ted, that's just a speculation. Actually, it's not. The Toronto Star did a survey a while back and found that a vast majority of corporations block all forms of social media. While F-B was not specified, it is a social site. I do not believe it to be speculation to extrapolate to include, at least, the States. Especially, with all the posts I've seen stating that they can't get there from there. Don't get me wrong, I'm not denigrating social media (I actually subscribe to a lot of them; I have FaceBook, LinkdIn Twitter active on my BlackBerry Torch [9800] all the time. What I don't understand is why choose a channel that is likely blocked? But, I have no intention of making this thread into another drawn out argument -- you are obviously successful with your product and dissemination of information. But, I will do something I don't normally do. I shall volunteer to conduct a straw poll, open until Friday @ 1800 EST (Canada). To not clutter this list, and my usual inbox, io have created a (throw away) e-mail account for this purpose. If you wish to participate in the survey, send your response to edwardamacn...@yahoo.ca. The survey says: Does your company block access to: 1. Social Media, in general? 2. FaceBook, specifically? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)
Why are vendors and organizations using Facebook for professional use? I am seeing this more and more often. Our use of Facebook is experimental at this stage... We are trying it for several reasons. First, because I (and a LOT of other people) do use Facebook socially, so I (and a LOT of other people) are somewhat familiar with it. Second, it is a very convenient way for us to push information and for interested recipients to receive that information... * Recipients (customers, usually but anyone actually) can opt in or opt out of our posts by liking or unliking (awful terms!) our ColeSoft page. * So the recipient list is self-selecting. We don't have to maintain it. * In fact, we do not have (and there is no way we could have) a complete list of people who use z/XDC and are interested in its developments. Our Facebook page gives such unknown people an easy way to stay abreast of z/XDC developments if they choose to. * Recipients can react to our announcements or even create their own postings there, so the Facebook page can also serve us as a product forum. * Posting information on Facebook does not require web programming skills, so it widens the range of people here at ColeSoft that can be assigned to maintain the presence. Third, this kind of posting does not appear at our website because customers don't frequent colesoft.com anywhere near as much as they frequent social websites, especially Facebook. So only the most important information goes there. But we do have access to LinkedIn (as of yesterday, anyway). I prefer Facebook over LinkedIn simply because I don't use LinkedIn, don't know how to use LinkedIn and have no interest in learning LinkedIn. Why? Primarily because it seems to me to be just a redundancy to Facebook. And more people use Facebook than LinkedIn, so why bother? And no, I'm not going to give Facebook my details just to chase down company announcements. About the only real information you have to give Facebook is an eaddress. There is nothing else that they require you to give. I'm not a z/XDC user, but I didn't see the information on your web site. At least not in any obvious place. Customers know to look in our Support area for maintenance details. My Facebook post contains additional prose regarding the fixes. I'm not a z/XDC customer either, but if I was I would consider this to be a problem. I do not use Facebook and I have no intention to do so. Major announcements will still find a place at our website and a brief mention in IBM-MAIN and ASSEMBLER-LIST. By definition, it [Facebook] is primarily used for networking with friends, not professional contacts. You're posts are an exception. Ummm, I find that a very large number of both local and national businesses have growing Facebook presences. So I don't agree that my posts are an exception. After all, if half a billion people are on Facebook, then by definition(!), that's where your customers are... Personally, I use Facebook more to keep up with local (Nelson County) events than for following friends... Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)
At 5/23/2011 03:44 PM, Rick Fochtman wrote: I'd also be concerned about too many wanna be's cluttering a professional's mailbox with inappropriate and/or senseless replies to legitimate technical questions. (a) Could happen. (b) Might not. Personally, I doubt it will be a problem. But if I choose a, I certainly will learn less than if I choose b. I'll choose b. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)
Thanks for the smile, Ed. vbg Dave At 5/23/2011 05:49 PM, Ed Finnell wrote: _http://www.dilbert.com/2011-05-22/_ (http://www.dilbert.com/2011-05-22/) In a message dated 5/23/2011 4:47:15 P.M. Central Daylight Time, dbc...@colesoft.com writes: But if I choose a, I certainly will learn less than if I choose b. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)
FWIW, I just checked and the number of opt-ins (likes in Facebook parlance) is up a bit over 20% since my post. So there's some opinion out there that's not been expressed in this thread. Just saying... But the total is still a substantial minority of our customer base, so all you Eff-book phobes out there don't have to worry ... yet. [;)] Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Recent maintenance for z/XDC
I have posted new maintenance for z/XDC. For details please visit our Facebook page. You can find it by going onto Facebook and searching for ColeSoft. Thank You, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/XDC Release z1.12 now avaiable
I'm curious. What did you find? At 1/20/2011 03:47 PM, Edward Jaffe wrote: On 1/18/2011 1:46 PM, David Cole wrote: z/XDC release z1.12 is now fully available. Major new features include: Installed and operational here. Already found a use for one of the new facilities. Great job, Dave! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/XDC Release z1.12 now avaiable
I'm betting you will use that a lot... At 1/21/2011 02:36 PM, Edward Jaffe wrote: On 1/21/2011 10:40 AM, David Cole wrote: I'm curious. What did you find? Programmer can now (fairly easily) display storage being accessed in a JES2-owned data space by an SRB-mode program. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/XDC Release z1.12 now avaiable
z/XDC release z1.12 is now fully available. Major new features include: - SRB debugging support improvements - New reporting commands regarding access lists and data spaces - The ability to access (display and zap) data spaces that previously were not accessible - Improvements in formatted storage displays - New Helper Dialogs for assisting with various debugging processes (in progress) - Full support for all of the new z/Enterprise 196 machine instructions - Infrastructure for planned new capabilities For more details, please check www.colesoft.com/PressRelease/110118_z112release.html. (Or just go to colesoft.com and navigate from there.) I want to thank those of you who made our beta program a success. Your comments and suggestions were quite helpful. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why does TEST ... (Comments WRT z/XDC)
At 11/9/2010 04:23 PM, Binyamin Dissen wrote: Why does TEST cancel breakpoints on BRC instructions? Any ideas why this weird restriction exists? z/XDC does not have this restriction. At 11/9/2010 05:45 PM, Rick Fochtman wrote: I seriously doubt if TEST has been updated in donkey's years. I've noticed other restrictions. z/XDC continues to be actively developed. Example: When IBM GA'd the z/Enterprise this past September (which has over 100 new machine instructions), we released to beta test our support for those new instructions only 3 days later. At 11/9/2010 05:52 PM, Starr, Alan wrote: I'm reasonably sure that TEST / TESTAUTH establish a breakpoint by actually replacing your code at that address with X'0A3D' (i.e. SVC 61). Almost correct. The breakpoint SVC is 97, not 61. SVC 61 is used in deferred breakpoint support. When TEST is running (TCBTCP=1), Contents Supervisor issues SVC 61 (after it places a load module/program object into user storage) so that deferred breakpoints, if any, can be set. At 11/9/2010 05:52 PM, Starr, Alan wrote: This [the breakpoint SVC] is the fundamental reason why there are some instructions which may not be breakpointed (e.g. EX or the target of EX). z/XDC does not have either of these restrictions. We fully support breakpoints both on an EX (and EXRL) or on their targets or on both the EX/EXRL and their targets simultaneously. Support for doing this is simplified because we use 1-byte wide X'00' opcodes for our breakpoints, not 2-byte wide SVCs. Imagine what happens when an EX target is replaced by an SVC 97. When the EX is issued, the SVC number can be changed from 97 to a large number of other values. Thus, a random SVC would be issued, not SVC 97. And so, not only would TEST not receive control, but random wonderment would also ensue. Now imagine the same scenario but in XDC's case where only one byte is changed (to X'00'), not two bytes. Then when the EX is issued, an 0C1 occurs, not a random SVC. Thus, XDC will always receive control and will recognize and process the 0C1 as a breakpoint, just like normal. At 11/9/2010 07:47 PM, Brian Kennelly wrote: The offset in a BRC is relative to the instruction, whether it is executed directly or by EX, so you cannot easily execute it out of line without recalculating the offset or simulating execution. It is easier to restore the instruction and execute inline. Bingo! In any case, z/XDC does not have this problem because all breakpointed instructions are run by actually running them in place in their true execution environments (not EX'ing them from the debugger's environment). Accordingly, z/XDC has had mechanisms from day one [back in 1980!] for restoring ATs once execution has moved past them. This design permits z/XDC to support placing breakpoints on EVERY machine instruction that z/Systems supports! regardless of how it affects the execution flow or environment. (Well... every instruction that I know about. And... uh... not on SIE. Sorry). But even for unpublished instructions, z/XDC breakpoints will work as they should just so long as those instructions don't branch. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.xdc.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
At 10/14/2010 07:54 PM, Rick Fochtman wrote: snip For example, why do IDCAMS and IEBCOPY have to be authorized? The IEBCOPY replacement doesn't have to be authorized. Would it be worthwhile for both vendors and users to see what they can do to reduce the amount of code that has to be authorized? [snip] Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since they are loaded from SYS1.SVCLIB. When IEBCOPY was converted from MVT to MVS, the developers at the time wanted to make it run as fast as possible. Also, IEBCOPY might have been a good vehicle for testing/experimenting with those wonderful new interfaces. Certainly, there is no technical reason in the world (at least I don't know of one) why a functionally identical could not be written that did not require authorization... It's probably a matter of It ain't broke, so for god's sake don't fix it! Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
At 10/13/2010 10:26 AM, Greg Shirey wrote: I liked this article, and it's fairly recent. (Jan 2010) http://www.mainframezone.com/it-management/mainframe-hacking-fact-or-fiction/P1 Greg I read that article, and it is a good one. Interestingly (to me at least), on the article's third web page, there is an excerpt from a post I made here in 2006. It's nice to know that someone is paying attention. My entire post can be found at: http://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=147B1F23465267AA41Y=dbcole%40colesoft.com I think the information in that post are highly relevant to the current thread. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: When will MVS be able to use cheap dasd - 24/7 DASD on PCs
At 10/8/2010 03:35 PM, Rick Fochtman wrote: -unsnip- My 2 cents worth: the cheap DASD doesn't live up to the reliability standards that IBM demands for z/OS. Stop and think, really hard, about the demands on z/OS DASD storage, as opposed to the standards you enjoy with your PC DASD. How many of your PC's stay up, with DASD spinning, on a 24/7 basis, for several years without problems? Rick FWIW: We've run around 10 PCs 24/7... for years! One for a decade! The hard drives do just fine... Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
At 10/14/2010 12:24 PM, Chris Craddock wrote: (as Bob knows) it is impossible to create/install a malicious FLIH or SVC or PC without already having the keys to the kingdom anyway. That is the foundation of integrity and the reason why the installation has to appropriately protect system datasets and APF libraries. Well that's just the problem, Chris, isn't it... The keys to the kingdom really are not well guarded. That's what my 2006 post was all about. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Please disregard prior email from LEA COLE. It's biogus. We got hacked. Sorry
If you just now received an URGENT HELP NEEDED email from my wife, Lea Cole, please disregard it. Here gmail account got hijacked. We're trying to fix it now. Sorry, Dave Cole -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/XDC release z1.12, beta #2 posted: z/Enterprise machine instructions supported
Hi All, I have just posted beta build #2 for z/XDC's upcoming release z1.12. z/XDC is a development and debugging tool for Assembler Language code. This build includes support for the new z/Enterprise machine instructions (all of them). Also, this release includes a growing set of Helper Dialogs (sorta like Wizards) to help with using some of z/XDC's more complex features. More information can be found at www.colesoft.com/PressRelease/100816_z112beta.html. Existing z/XDC customers can get access to the beta by contacting me. Thanks, Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS V1.12 differences and z196 (the new mainframe) impacts
At 9/13/2010 09:23 AM, Paul Gilmartin wrote: On Mon, 13 Sep 2010 06:35:45 -0600, Steve Comstock wrote: * GETMAIN now returns address of gotten area in R1 with the leftmost word being all binary zeros, so address can be treated as a 64-bit address Unconditionally? That would break subroutines that don't save/restore high order parts. (Or does R1 not matter?) -- gil Gil, I once raised a similar question with Peter Relson. He unequivocally asserted that no program can rely upon any part of (including the high halves of) the volatile registers (r15, r0 and r1) being preserved across system interfaces (unless the interface doc states otherwise). Here's the quote: At 3/18/2007 08:07 AM, Peter Relson wrote: Dave, Except for regs 0,1,15 your assertion is true. The high halves of those regs are not preserved across any interface unless otherwise documented. This is documented in the assembler services guide 2.1 Saving the Calling Program's Registers [snip] This is in contradiction to a verbal statement he made at a presentation several years earlier wherein he flatly stated that no preexisting AMODE(24/31) program would ever behave differently (due to the widening of the registers) when run in z/OS vis-a-vis OS/390. Unfortunately, I don't have the video. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3270 Emulator Software
David Cole ✆ to IBM show details 6:19 AM (25 minutes ago) Quoting from http://tinyurl.com/3xybhe8: Each individual Samsung LCD has a 19-inch diameter screen Uh ... Diagonal? On Sat, Aug 28, 2010 at 7:52 PM, Edward Jaffe edja...@phoenixsoftware.comwrote: Ed Finnell wrote: Don't be such a piker http://tinyurl.com/3xybhe8 Now you're talking! 8-) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PoPs
Rick, The -08 edition of the PoPs won't be out until September sometime. Meanwhile, what *IS* published is this: http://share.confex.com/share/115/webprogram/Session7034.html Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 8/22/2010 04:37 PM, Rick Fochtman wrote: Could one of you fine ladies or gentlemen kindly download the PF of the latest Principles of Operations and E-Mail it to me as an attachment? (I'd also accept BookManager format, but I'm told that it's not available.) I am having no end of difficulty in getting any sort of access to that page. It asks me to sign up, then tells me I'm already signed up. When I try the reset password mechanism, it tells me that I'm not a registered user. Can we say Circular logic??? Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/XDC announcement: Release z1.12 is now available for beta test
z/XDC release z1.12 is now available for beta testing. Major new features include: - SRB debugging support improvements - New reporting commands regarding access lists and data spaces - The ability to access (display and zap) data spaces that previously were not accessible - Improvements in formatted storage displays - New Helper Dialogs for assisting with various debugging processes (in progress) - New z/Enterprise machine instructions (planned) - Infrastructure for planned new capabilities For more details, please check www.colesoft.com/News. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File 120 now has 2 new articles
WOW! Of all the tools available on PCs for writing and packaging content, why on EARTH would you choose .XMI ! That certainly will keep your circle of readers ... umm ... exclusive. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 6/7/2010 11:13 PM, Sam Golob wrote: Hi Folks, Since I stopped writing for NaSPA's Technical Support magazine, it doesn't mean that I've stopped writing articles completely. On File 120 of the Updates page of www.cbttape.org, the articles prefixed by member names: BM** are owned by me, and NaSPA doesn't have any connection with them. There are two new articles there now (on the Updates page), with member names BM1005MY and BM1006JN. I trust you will find them interesting. All the best of everything to you and yours Sincerely,Sam Golob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Need tool to zap core
It's not free, but z/XDC will do the trick. Even more, it can also zap storage that's been made read only (such as the PLPA, read-only sections of the nucleus, and any other page that has been made read-only by the PGSER macro). If your client has z/XDC, then this would be an easy way to accomplish what you want. Dave Cole At 2/24/2010 11:21 AM, Pinnacle wrote: I have a need to zap core, but my client does not have OMEGAMON. I searched the CBT mods tape and came up empty. What we're trying to do is a SETPROG LPA,ADD, but of course, there's a vector table that needs to be updated with the address of the new module. This is not an SVC, so my only recourse to install this without an IPL is to zap core. Are there any freeware tools out there for zapping core? Regards, Tom Conley Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler variable with @
I sometimes use a trailing @ (in a symbol's name) as a personal convention to indicate that the field contains an address. But as noted elsewhere, the Assembler treats the @ (and the $ and the #) no differently from an alphabetic letter. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 On Tue, 16 Feb 2010 16:44:40 +0100, MONTERO ROMERO, ENRIQUE ELOI enriqueeloi.mont...@servifactory.com wrote: Hi team, Hope you are well, This time is an assembler coding question. What does it means an at-sign (@) at the end of a constant? Example : R1 EQU 1 R2 EQU 2 R3 EQU 3 LIST@ EQU 4--- ? R5 EQU 5 R6 EQU 6 PARM@ EQU 7--- ? R8 EQU 8 R9 EQU 9 R10 EQU 10 R11 EQU 12 ... ... Also in this code : L PARM@,0(LIST@) --- ? MVC DSNAME+4(44),0(PARM@) --- ? Is there some especific situation to put the @ ? Thannks a lot in advance, Enrique Montero -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
New DSCOPY Program Posted
I have just posted to ColeSoft's website a new version of my DSCOPY program. The link is www.colesoft.com/Downloads/downloads_utilities.html. DSCOPY and everything else that you find on that page is free. DSCOPY is a generalized sequential file copying program. It features include the following: 1.) DSCOPY can perform any number of separate copies in one jobstep. 2.) Input datasets may be sequential, direct, or individual members of partitioned data sets, or a concatenation of any combination of the above with any combination of DCB attributes (RECFM, LRECL, and BLKSIZE). 3.) Unlike-concatenations of input files are fully supported. Any input file may be a concatenation of any supported datasets having any combination of DCB attributes. 4.) Any record format is allowed (fixed, variable, undefined) for input, and it may be changed to any other record format for output. In addition, logical record lengths and/or block sizes may also be changed. All such changes are automatically accommodated for. 5.) All information needed is specified through JCL or through the PARM field. No control dataset (SYSIN, for example) is needed. 6.) Optionally, all 1st-quadrant bytes codes can be changed to periods or blanks. 7.) Optionally, a large number of date related built-in symbols are supported that can be replaced by either UTC-time related or local-time related date/time values. 8.) DSCOPY contains basic support for copying only a portion of a dataset. (Sam, if you're here, could you do me a favor? If DSCOPY is still on the CBT mods tape, could you take it off and replace it with the above hyperlink? Thanks.) I need a short break from the code this afternoon, so I'm going to indulge myself with a brief walk down memory lane. The more here-and-now guys among you might want to stop reading at this point. For the rest ... I have been using DSCOPY for almost exactly 40 years now! I wrote the first version in 1969. I had just changed jobs. I had been working for the University of Pennsylvania's Computer Center (UPCC), and was beginning a new job for one of their commercial customers in downtown Philadelphia. UPCC was running MFT with HASP (JES2's predecessor), and the SYSPROGs there had written an RYO charge-back system that was completely implemented as locally written mods to HASP. (HASP was a perfect place to measure CPU seconds, I/O bytes, cards read/punched and lines printed because it had intercepts all over the system, including in the various interrupt new PSWs.) Anyway, while working at UPCC, I discovered that their charge back system had an interesting flaw: It did not begin to accumulate accounting stats for any job until that job did it's first read/write from/to a card reader, card punch or line printer (spool, actually). So... If you could put all your sysin into files and write all your sysprint out to temporary files, and then have a single, final jobstep that would write all of those files, regardless of DCB attributes, to the printer, then you could save a boatload of money! (Real money, in the case of a commercial customer ...) So I wrote DSCOPY... Needless to say, it did not take UPCC long to find/fix their bug. DSCOPY was one of my earliest Assembler programs. I had just begun to learn Assembler only a year or two before. (I was a FORTRAN programmer before that.) When I wrote DSCOPY, there were two things I wanted to achieve. One was to be able to copy any number of sequential files having any arbitrary DCB attributes, and to transform those attributes in any way reasonable and as needed by the output files/devices. So I learned a lot about DCB OPEN exits. The other was to make it blindingly fast! At the time, pretty much the only sequential copying program available from IBM was IEBGENER, and it was abysmally slow! The way it did I/O basically led it to read/write exactly one physical block per revolution of the DASD device. If the file happened to be unblocked then oh my gawd! So in the process of trying to make DSCOPY fast, I had to learn about such things as DCBs, DEBs, IOBs, PCI CCW programming, chained scheduling and track capacity calculations. (A 2314, for example, held forty 80-byte blocks per track.) I still wound up just using QSAM, but I did it right. I used PUT-LOCATE mode buffering, I used OPTCD=C, and I used NCP=nnn where nnn was (where possible) the exact number of blocks that could fit on a track. So DSCOPY would usually be able to read/write an entire track's worth of data on a single rotation. Nowadays, DSCOPY is still fast, but so is everyone else, so speed no longer is its advantage. But IMO it's still awful damned useful! Feel free to take it, try it, and use it. Let me know how it goes ... Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX:
Re: Mainframe hacking (getting back on topic)
At 7/20/2009 04:49 PM, Patrick O'Keefe wrote: I think you were saying that you have the keys to the realm if you are an authorized program and IBM requires authorization for far too many services, so it is far too easy to stick back-door code in a program that needs to be authorized. Basically, yes. That certainly is a hole in mainframe security, but I don't think of that as a hacking issue. (I'm going to assume the hacking in the original posting was meant to imply a breaching of MVS security by outsiders where outsiders could be either outside the company or outside the group of legitimate users - a meaning real hackers would find very offensive.) My issue is mainframe security and what seems to me to be a rather complacent and unfounded attitude that MVS security is bulletproof. It is not bulletproof for the reasons that I discussed in my prior post. To divide the issue by the distinction of insider vs. outsider obscures the threat. First of all, WRT an inside threat, I grant that a person posing such a threat would first have to get past many (well, hopefully many) other security barriers before being able to exploit the authorized libraries vulnerability. But I don't think that therefore one should be unconcerned about the vulnerability. WRT an outside threat, I am willing to accept (and I acknowledged this in my prior post) that the z/OS's defense against non-APF authorized threats is bulletproof. But then to just leave the issue there is, I think, complacent. The presumption seems to be that no outsider would have the ability to put a program into APF authorized libraries. Well, what about 3rd party vendors? We certainly provide the motivation to induce insiders to place our programs into authorized libraries. But what are we? Insiders? Outsiders? (As mentioned in my prior post, one technical way to partially address this exposure would be for IBM to reduce the number of reasons requiring a program to run authorized.) That certainly is a hole in mainframe security, but I don't think of that as a hacking issue. I dunno. Wouldn't Trojan Horse fall into the category of hacking? I think hacking around or through MVS security is very rare. I certainly hope so... But by no means would I consider myself qualified to make that assertion. FWIW, this sort of vulnerability is by no means limited to mainframes. The PC world is plagued by this problem. In other words, the model is out there. If Western Civilization Runs on the Mainframe, then it's only a matter of time before someone will find that it's worth the effort to write a gotta have Trojan Horse. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Partners WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 7/20/2009 04:49 PM, Patrick O'Keefe wrote: Maybe the result was silence that time but the general topic has been discussed a number of time in a number of venues. I think you were saying that you have the keys to the realm if you are an authorized program and IBM requires authorization for far too many services, so it is far too easy to stick back-door code in a program that needs to be authorized. That certainly is a hole in mainframe security, but I don't think of that as a hacking issue. (I'm going to assume the hacking in the original posting was meant to imply a breaching of MVS security by outsiders where outsiders could be either outside the company or outside the group of legitimate users - a meaning real hackers would find very offensive.) Writing a back door is an inside job. It could be an interesting hack, but I don't think that's what the OP meant. MVS security (when used) does a good job of keeping outsiders out, but no system on any operating system is safe from those that are given the authority to bypass the security. Pat O'Keefe I think hacking around or through MVS security is very rare. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Does anyone here recall any published news articles or incidents involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you personally know of any incidents? Or have any such been kept on the QT? A couple of years ago, there was a thread called Back doors. I posted something there about the vulnerability of z/OS to hacking. Here's the link: http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=2F4EDA1D0DDA5823A7-Y=dbcole%40colesoft.com (The resulting silence was deafening.) Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Partners WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Steve, Yeah, that link goes to IBM-MAIN's archives, and you need a your email address (which IBM-MAIN already has) and a password to access that post and the thread in which it lives. I've made a copy of my post at my own website. Here's that link: http://www.dbcole.com/misc/rebackdoors.html Dave Cole At 7/20/2009 02:03 PM, Steve Comstock wrote: Dave, It sounds really interesting. But the link takes me to a page where it is asking me to login and it has pre-filled in your email address. Just a heads up. Kind regards, -Steve Comstock The Trainer's Friend, Inc. David Cole wrote: Does anyone here recall any published news articles or incidents involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you personally know of any incidents? Or have any such been kept on the QT? A couple of years ago, there was a thread called Back doors. I posted something there about the vulnerability of z/OS to hacking. Here's the link: http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=2F4EDA1D0DDA5823A7-Y=dbcole%40colesoft.com (The resulting silence was deafening.) Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Partners WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Announcement: Release z1.10 of z/XDC is now available
For Assembler Programmers: I have just posted our latest release (z1.10) of z/XDC. For more information, contact Bob Shimizu at r...@colesoft.com. Thanks Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Partners WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slightly crazy idea to speed up EX instructions (XDC issue?)
On Feb 19, 2009, at 14:43, David Cole wrote: The reverse case, though, is problematic: When you EX the immediately following instruction, z/XDC's tracing process can get stuck. Years ago, though, I had one customer who actually liked this defect. When he learned of this, he immediately started using such code sequences as gatekeepers to try to keep an XDC user out of code that he wanted to keep secret. (Or at least make tracing it exceedingly inconvenient.) At 2/19/2009 05:04 PM, Paul Gilmartin wrote: Oops? Breakpoint code overlays the EX target? A suitably enhanced z/XDC should be able to handle this. Hi Paul, In all cases *except* the EX *+4 case, XDC does handle things correctly. In particular, XDC is perfectly fine with setting a breakpoint either on the EX or on its target or on both! (In the both case, XDC will receive control first for the breakpoint on the EX, then second for the breakpoint on the target, before allowing the code to move on [.org].) But I'll readily agree if you say it's worth neither the execution overhead nor the coding resource. Coding a solution for the EX *+4 case was not, as they say, commercially feasible. (Coding solutions for the other cases was, in my youthful exuberance, fun!) Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Partners WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Name/tokens
This is a bizarre response, Peter. Several of us have documented our need for a name/token list/search service, a need that we've felt strongly enough about to actually go to the trouble of writing complicated workarounds to your failure to fulfill that need. What more do you want by way of demonstrating a need? it seems pretty clear to me that you should not take an approach that requires such a service. Our needs dictate our approaches, Peter. If you feel that my product does not need a list/search service, then feel free to quit IBM and come work for me and find a better way to code to my product's needs. If you feel that we are not competent enough to correctly determine our own needs, then why are you even talking to us? David Cole At 9/11/2008 07:28 AM, Peter Relson wrote: Every response to my query seems to have missed the point and put the cart before the horse. I don't disagree that it is desirable to have a list service for name/tokens. What I question is the need. Since a list service does not exist, it seems pretty clear to me that you should not take an approach that requires such a service. You are welcome of course to ask for such a service and, after/if it is made available, exploit it. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Name/tokens
At 9/10/2008 09:50 AM, Rob Scott wrote on IBM-MAIN: Peter, In the past, I have seen software that uses part of the name as a constant prefix and then places variable information in the later part of the name (maybe ASID, TCB or subsystem instance or whatever the developer wanted) - I imagine this can happen when the token part is already full. In this case the ability to list the name/tokens for search purposes would be desirable. Ditto. z/XDC used to keep track of certain control data via ENQs. The RNAMEs all were control data that started with an identifying keyword followed by specific data. I could then use GQSCAN to search for and return all instances of a desired control data type simply by specifying a GENERIC scan for the first n bytes of the RNAME. Some 6 or 8 years ago, I had reason to switch from using enqueues and GQSCAN to using name/token services. What should have been a rather straightforwards conversion turned out to be immensely complicated by the fact that name/token services did not in any way support generic searches! It was a major P.I.T.A.! That's my nickel's worth. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.xdc.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Code Page 1047 vs 037 - 3278T setting
At 7/8/2008 05:41 AM, Larre Shiller wrote: At 7/7/2008 06:55 PM, Edward Jaffe wrote: Try setting your terminal type in ISPF Settings to '6' = 3278T. Ed - I don't know how you figure this stuff out, but that did the trick! Amazing...! Thanks! Larre Shiller US Social Security Administration 410.965.2209 www.ssa.gov Yeah, Ed. How do you figure these things out. More specifically, what the heck is 3278T, and what is different between it and, say, '3' = 3278 ??? (Or, where can I go to read about this stuff myself?) Thanks, Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Code Page 1047 vs 037 - Green card confusion
At 7/7/2008 12:15 PM, Edward Jaffe wrote:
They [code pages 1047 and 037] are not the same. [snip] People still
using the old code page 037 probably see funny looking garbage
characters in IBM-provided macros and other code. [...]
On Mon, 7 Jul 2008 09:01:02 -0700, Edward Jaffe wrote:
I haven't used code page 037 since the mid-1990s. I think just about
everyone here uses 1047.
So what I'm hearing is that code page 1047 is somehow better than
037, and for all I know that may well be true. BUT have you (anyone)
looked at the green card in recent years?
In SA22-7871-00 (SEP01) and SA22-7871-01 (JUN03), the Code
Assignments table shows 5 EBCDIC charts titled 81C 94C 037 500 and
1047. (That's cool, I thought.)
But starting with SA22-7871-02 (SEP05) and continuing to this day
(SA22-7871-04 [FEB08]), the dorks threw out 81C 94C 500 and 1047, and
kept only 037. Well, that leads to two questions:
(1) If 037 is better than 1047, then why did IBM drop it from the green card?
(2) But more importantly, why on earth did IBM drop 81C 94C 500 and
1047 from the green card in the first place? That was damn useful information!
On a related note...
At 7/8/2008 08:53 AM, McKown, John wrote:
I don't know the code page involved, but the GX20-0157-2 (System/370
Extended Architecture Reference Summary) has a section entitled
CODE ASSIGNMENTS which put { at 0x8b and } at 0x9b.
SHESSS!
Dave
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2
The OP is an ISV concerned only about his own internal product GEN process. At 5/27/2008 10:40 AM, Paul Gilmartin wrote: If, as we may suspect, the OP is an ISV targeting customer platforms, he may encounter difficulties with customers' job name standards? Is there a scriptable way to release other than by job name? -- gil Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
The Mellon Bank Mods were written prior to JES2's ability to run more than one converter process. Consequently, they do not guarantee serialization for the same reason that CNVTNUM=2 users don't get serialization. For more info, see: http://bama.ua.edu/cgi-bin/wa?A2=ind0805L=IBM-MAINP=R89127X=5479D13E719614079CY=dbcole%40colesoft.com Dave At 5/27/2008 10:51 AM, Hal Merritt wrote: Doesn't anyone remember the famous 'Mellon Bank Mods'? Among several other useful features, they offered /*BEFORE, /*AFTER, exclusivity (any job, but only one of a thread at a time), and so on. They died out many moons ago, perhaps because they mods became a upgrade nightmare, or perhaps it was the OCO. More, the job schedulers became sophisticated and powerful enough to handle the most complex of these issues. So, my $0.02 (before taxes) would be to consider a job scheduler. One big benefit is you can have one tomorrow as opposed to waiting potentially years for IBM to consider JES modifications. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2
At 5/23/2008 05:58 PM, Shane wrote: On Fri, 2008-05-23 at 10:27 -0700, Edward Jaffe wrote: Actually, JES3 *is* available as a free alternative in Dave's new development home. Define free - it may not cost any more (presuming Daves new home is Dallas), but the effort might not be insignificant if Dave (or his people) isn't JES3 literate. Dave AND his people arn't JES3 literate. At this point, there's not much hope for Dave, but he has good people, they can figure things out. However, as noted previously, I already have my solution. So... why bother? Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Thanks Sam! You're response was immensely better than mine would have been. Dave At 5/23/2008 10:11 PM, Knutson, Sam wrote: OTOH IBM-MAIN is a great place to brain storm and refine a requirement before submitting it to IBM as a marketing request or through SHARE. A unique audience of customers, ISV developers, and IBM folks exists here that is usually not available to comment unless you stumble into the right hotel bar during the week SHARE is in town:-) Complaints voiced here may lead to others pointing out available solutions or full understanding of the history that lead to the current behavior. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Friday, May 23, 2008 6:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix) I think it is a shame that the IBM-JES2 folks make it so difficult to serialize a thread of jobs. It seems to me that this is such an obvious thing to want to do, but when JES2 is started with CNVTNUM=2 (and there are strong reasons for must shops to want to do this), such serialization becomes problematic. The thing is, a JES2 supported solution, it seems to me, would be both ideal and easy to implement Blather! Blather! Blather! IBM does not take complaints on IBM-Main as requirements. You want changes? Go through the channels. I'm sorry it doesn't work as desired, but b*tching here will not change anything. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
At 5/24/2008 12:16 AM, Kenneth E Tomiak wrote: Just because David would JES2 to handle scheduling does not mean implementing it would be easy. Laying out how he would like the interface is but the tip of the iceberg. As indicated in my post, I've had experience as a JES2 programmer (about two decades worth). By that I mean, that once upon a time I knew intimately the details of JES2's internal structures and logic, and that I wrote many dozens of simple and complex mods to JES2 (and HASP) for various employers from the '60s (at Rutgers, then Yale) into the '80s (for DC bandits). So my estimate, that implementing the support that I suggested would not be too difficult and could be done in a matter of weeks, was based on experience, not random guessing. Certainly, my suggestion is potentially just a first step in a far more complex set of issues that arise should you decide to expand my idea into a more comprehensive job networking solution, but I was by no means suggesting that. After all, as is well known, there already are 3rd party solutions that deal with those complexities quite well. All I was suggesting was a very simple mechanism by which jobs could be guaranteed to run in the order submitted, nothing more, nothing less. This guarantee is already there for some JES2 users (those with CNVTNUM=1). Why not make it possible for everybody? At 5/24/2008 12:16 AM, Kenneth E Tomiak wrote: Just because David would [want] JES2 to handle scheduling does not mean implementing it would be easy. Laying out how he would like the interface is but the tip of the iceberg. Entering real requirements to IBM is one way. He can also get a job with IBM, become the head of JES2 and fight for his cause. Saying that what I proposed is my cause is a bit of an overstatement. ;-) I was just making a suggestion, not a demand. As I've already noted, I already have my solution to the problem. Saying that I wanted JES2 to handling scheduling also is an overstatement. All I did was suggest a very simple way by which JES2 could be changed so that it could guarantee job sequencing, should a user want it. That is a far cry from job scheduling. At 5/23/2008 11:16 PM, Paul Gilmartin wrote: On Fri, 23 May 2008 14:16:55 -0400, David Cole wrote: As noted in my prior post, I think it is a shame that the IBM-JES2 folks make it so difficult ... And that JES2 doesn't do device setup and highwater mark reservation, and that JES2 doesn't verify data set availability, and that JES2 doesn't do better syntax checking, and that JES2 doesn't check for duplicate DDNAMEs within a step, and that JES2 doesn't balance load across systems, and ... If JES2 did everything that JES3 does, it wouldn't be JES2 any more, would it? Am I right in assuming that JES3 costs more than JES2? Doesn't the vendor, then need to provide differentiating features to justify the expense? Of course, it's only human nature to wish that one's only favorite feature were added as an enhancement to the lower priced product. I am not suggesting a convergence between JES2 and JES3 (although there has already been a considerable amount of that since the old HASP vs. ASP wars). I also am not suggesting anything that would be complex or difficult to implement (such as the several JES3 features that you referenced). I was just saying that it would be such a simple thing to do, and that because it is so simple, I feel that it's a shame that IBM doesn't do it. At 5/23/2008 11:16 PM, Paul Gilmartin wrote: Am I right in assuming that JES3 costs more than JES2? I don't think that you are correct (at least not directly). IIRC, JES2/JES3 is just a choice you make when ordering a system. There is no additional charge for either. (But also IIRC, doesn't JES3 consume more resources than JES2 and so costs would be increased in that way? Our are my prejudices obsolete?) Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Controlling the execution sequence of dependant jobs in JES2
Hi, I have a process that submits up to a couple of hundred jobs for execution. I require that these jobs execute in the same order in which they were submitted. For decades I have accomplished this by assigning all of the jobs to a specific job class and then insuring that there was never more that one initiator that had that job class assigned. I am now running at a new data center. (Guess where...) And I have just discovered that my jobstream is running out of sequence. For some reason, my single-threading initiator is selecting jobs from the input queue out of sequence. Is there an official way to enforce job execution sequencing? TIA Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2
At 5/23/2008 04:58 AM, Ted MacNEIL wrote: |Is there an official way to enforce job execution sequencing? JES2 has never guaranteed that jobs will execute in the same order as submitted. It depends on how long it takes to convert. Bingo. Thanks for jarring my memory. So I went to the books (imagine that) and found: Initialization and Tuning Guide Controlling JES2 processes Job selection and execution Controlling the sequence of job execution Serial job execution sequence (aka: http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.hasa300/has2a360.htm;) and relearned that I can specify CNVTNUM=1. (That works for me because we never use //JCLLIB.) Thanks Ted. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2
At 5/23/2008 08:25 AM, Mark Zelden wrote: On Fri, 23 May 2008 04:25:10 -0400, David Cole [EMAIL PROTECTED] wrote: Hi, I have a process that submits up to a couple of hundred jobs for execution. I require that these jobs execute in the same order in which they were submitted. For decades I have accomplished this by assigning all of the jobs to a specific job class and then insuring that there was never more that one initiator that had that job class assigned. I am now running at a new data center. (Guess where...) And I have just discovered that my jobstream is running out of sequence. For some reason, my single-threading initiator is selecting jobs from the input queue out of sequence. Is there an official way to enforce job execution sequencing? TIA Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 Schedrun? :-) Nope. :-( Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2
Thanks for the plug Chris, we appreciate it! As someone else on the thread pointed out, we are small enough that setting CNVTNUM=1 will work fine for us. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 5/23/2008 11:38 AM, Webster, Chris wrote: If you don't want to make the jobs submit each other and have no scheduling package, there is another alternative using UNIX tools (or windows). We have perl packages to do FTP (although you could also do it in rexx). Using make (or gnumake), you can make each job dependent upon the other. The completion of each job would cause the next to be submitted (make rules can be written to turn a .jcl into a .list or something like that). ...chris. (25+ years (satisfied) user of XDC (nee DBC)) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Friday, May 23, 2008 10:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Controlling the execution sequence of dependant jobs in JES2 At 5/23/2008 08:25 AM, Mark Zelden wrote: On Fri, 23 May 2008 04:25:10 -0400, David Cole [EMAIL PROTECTED] wrote: Hi, I have a process that submits up to a couple of hundred jobs for execution. I require that these jobs execute in the same order in which they were submitted. For decades I have accomplished this by assigning all of the jobs to a specific job class and then insuring that there was never more that one initiator that had that job class assigned. I am now running at a new data center. (Guess where...) And I have just discovered that my jobstream is running out of sequence. For some reason, my single-threading initiator is selecting jobs from the input queue out of sequence. Is there an official way to enforce job execution sequencing? TIA Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2 (the details)
At 5/23/2008 08:37 AM, Ted MacNEIL wrote: This is where scheduling package comes into play to prevent such incidents and tales of war stories describing such horrors. ;-D That assumes Production Batch. I don't believe Dave's stuff is Production. And, it's rare that non-Production is allowed to be managed by schedulers. Ok, just FYI, here's my specific situation. My need is for controlling the updates, assemblies and linkedits that I need to run when regenerating z/XDC. (It has nothing to do with the installation process at customer sites.) My typical gen jobstream is: * One update job. * Followed by from 1 to 175 assemblies. * Followed by one multi-step linkedit job. The assemblies may run in any order, but none may run prior to the update job, and they all must run one at a time, and all must run before the linkedit job. If assemblies abend or fail, I will still want to run the linkedit job since any given assembly failure will affect only one linkedit (out of the potentially 14 or so linkedits that might be in the linkedit job). For this, I do not need a thruput manager. The suggested solution of having each job submit its successor is not ideal for me because of the possibility of the succession chain being broken. (I do not want the gen to come to a screeching halt just because an assembly or two failed or abend'd. [Yes, I do know how to use COND=, but I also do not want to break the chain if I should decide to cancel one or more assemblies prior to their running.]) So serializing via JES2 is, to me, the ideal solution. It's just a shame that the IBM JES2 folks have allowed needless tradeoffs to creep into the serialization setup process. As I noted earlier, at my shop, specifying CNVTNUM=1 works just fine. I do not run a MAS, and (as it happens) I don't use //JCLLIBs. (And even if I did, I don't need or use archival/migration support.) Obviously, what works for me would not work for many other shops. I have an idea for how IBM could, rather easily, fix this issue. More about that in my next post. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
As noted in my prior post, I think it is a shame that the IBM-JES2 folks make it so difficult to serialize a thread of jobs. It seems to me that this is such an obvious thing to want to do, but when JES2 is started with CNVTNUM=2 (and there are strong reasons for must shops to want to do this), such serialization becomes problematic. The thing is, a JES2 supported solution, it seems to me, would be both ideal and easy to implement. Here's my idea: (1) support a //card option or a /*card option by which a user could provide an arbitrary serialization name. Example: /*JOBPARM THREADNAME=xyz. Use this name on each job in the thread. (2) Run the threaded jobs into a reader in the same order that you want the jobs to run. (Allow subsequent SUBMITs to add to a thread, if desired.) (3) The first converter to pick up one of the threaded jobs will always pick up the first one. (4) When that converter sees the thread name, it takes ownership of that thread such that all other converters will refuse to process jobs having that same name. Then, of course, the jobs would be queued for execution in the same order by which they were read, and if only one initiator ware assigned the thread's execution class, then they would, in fact, execute in that same order. There are, of course, several ancillary details: * Thread names will have to have some reasonable expiration interval. * $D/$T command will need to allow operators to display and manipulate threads to allow them to display and fix problems. * Some mechanism (ownerid perhaps?) need to be created to prevent unrelated threads having the same name from colliding. It's been several decades since I used to be a JES2 programmer, but from what I remember, it doesn't seem to me that this should be too hard. I'd guess that implementing such a scheme would take maybe only a week or few of my time. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
At 5/23/2008 02:23 PM, Staller, Allan wrote: WLM managed Init's? IIRC, Jobs are placed in queue in FIFO order within Service Class. The trouble is, your FIFO order is the order in which the collective converters finish processing their jobs and place them onto the execution queues. Because multiple converters process in parallel, and different jobs take different lengths of time to convert, the order in which jobs complete conversion can be different from the order in which jobs start conversion. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2 (the details)
Ever considered using SCLM? No. I've never examined SCLM. Sounds like I should get off by lazy butt and check it out. and it all runs in one batch job Well For a full gen, that would run to somewhere near a thousand steps. Doesn't that blow JES2's JCT limit? (or something like that...) Dave At 5/23/2008 02:30 PM, Rob Scott wrote: Dave, Ever considered using SCLM? - one of its strengths is controlling what actually has been updated and what to build as a consequence. There is some initial pain to define exactly what makes up the product using its own ARCHDEF language - however after that it is a breeze to re-gen the product - and it all runs in one batch job in the correct sequence. The price is right too. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2 (the details)
I'll be really, really off the wall. Why not use make? It can be set up to do the updates, then if they succeed, do all the compiles (and it can be told to ignore the RC of the compile), then do the linkedit. It really is set up to run off of UNIX files, but I'll bet there is a way to have it run standard z/OS programs too. But it may be too much of a PITA. I don't know. Interesting thought, John. Maybe I'll have one of the youngsters in the office check it out. Dave At 5/23/2008 02:34 PM, McKown, John wrote: From what I gather, you have three classes or stages of jobs. Stage 1 is the update. Stage 2 are the compiles. Stage 3 is the linkedit. You want stage 1 to finish before stage 2 starts. If stage 1 fails, do you want to continue with stages 2 (assemblies) 3 (linkedits)? After ever job in stage 2 ends, you want to run stage 3. The return codes on the jobs in stage 2 are irrelevant to stage 3 execution. Can SCLM be told to ignore the RC of the assemblies? I don't know SCLM. I'll be really, really off the wall. Why not use make? It can be set up to do the updates, then if they succeed, do all the compiles (and it can be told to ignore the RC of the compile), then do the linkedit. It really is set up to run off of UNIX files, but I'll bet there is a way to have it run standard z/OS programs too. But it may be too much of a PITA. I don't know. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Hi Sam,
You had me until I read this:
A few final notes concerning the relationship
between /*BEFORE, and /*AFTER. Many people try
to use these statements, and stack two or more
jobs in the same PDS member and submit them all
at the same time with one SUBMIT command. This
usually works as expected, but sometimes JES2
will NOT PROCESS the jobs in the order they
appear in the submitted member. This can result
in a job with a /*AFTER statement for a prior
job you think JES2 has already seen and
processed because of the sequence in the
submitted member, being processed and initiated
before JES2 ever finishes reading the job that
is the object of the /*AFTER statement. This
problem can be avoided by making sure that jobs
with /*BEFORE and /*AFTER requirements are
submitted separately from each other and in an appropriate sequence.
The disordering of the jobs that you refer to is
exactly the problem that my suggestion (THREADNAME=name) attempts to fix.
Thanks, though, for the memory lane stroll. I had
forgotten about /*BEFORE and friends, but your
post reminded me that I had first seen them when
I was working at a DC shop in the early '80s.
Dave
At 5/23/2008 02:35 PM, Knutson, Sam wrote:
Hi Dave,
What you describe is pretty much what the Mellon Mods for JES2 provided.
I would like to see equivalent function added to base JES2 by IBM.
Thruput Manager provides this function
too. Here is user doc for the Mellon Mods syntax for comparison.
Thanks, Sam
Users Guide - How to use the features of these Mods
- Control Statements
You take advantage of the Mellon Shared Spool mods via JECL
statements. There are currently five supported statements, they are:
/*CNTL XEQ resource, { EXC | SHR }
/*ROUTE XEQ secheduling environment name | HERE
/*WITH jobname
/*AFTER jobname
/*BEFORE jobname
The /*CNTL XEQ statement is used to add an additional job selection
criterion based on other executing jobs current use of the same resource
name. The /*CNTL XEQ must be placed in columns 1 through 10. The
resource name is arbitrary, and is made of up to eight (8) characters
with no embedded blanks. The resource name follows the literal /*CNTL
and must be preceded by at least one, but not more than 30 blank spaces.
If the shared (SHR) or exclusive (EXC) keywords are used, they must
immediately follow the resource name and be preceded by a comma. If
neither the SHR nor EXC keyword is specified SHR is assumed.
You may specify up to eight /*CNTL statements; additional statements are
disregarded.
Examples:
Assume jobnames ABC, and CDE are currently in execution with the
following /*CNTL XEQ statements -
//ABC JOB (other stuff)
/*CNTL XEQ MYNAME,SHR
//CDE JOB (other stuff)
/*CNTL XEQ MYNAME,SHR
Then if job EFG is submitted with the following, /*CNTL statement -
//EFG JOB (other stuff)
/*CNTL XEQ MYNAME,EXC
The job will not be selected for execution as long as either job ABC or
CDE continues to run.
Next if job XYZ is submitted with the following, /*CNTL statement -
//XYZ JOB (acctng info)
/*CNTL XEQ MYNAME Ú SHR is the default
It would be immediately available for execution.
When no jobs remain in execution with a /*CNTL XEQ MYNAME job EFG with
the EXC requirement would be available for job selection. Assume it has
now been selected, and a new job enters the system with the following
/*CNTL statement -
//WXY JOB (acctng info)
/*CNTL XEQ MYNAME
Job WXY will not be available for job execution until job XYZ that
holds the resource name exclusively ends. If other jobs are submitted
with resource names other than MYNAME, they will be treated separately
and only other jobs with /*CNTL statements that reference the same
resource name will affect their availability for job selection.
The /*CNTL statement only provides additional job selection criterion,
and does not replace other JES2 requirements for job selection such as
available initiators, appropriate job class and so on. The resource
name is arbitrary, you make it up, there is no need for anyone to add
the name to WLM, or any other table before it is used.
The /*ROUTE XEQ is a standard JES2 statement used to route your job to a
specific execution node. We have usurped the use of the statement, and
when we read an XEQ statement, we test to see if the name following the
XEQ literal is a valid WLM scheduling environment name. If the name is
a valid scheduling environment name, and if no schenv value is present
on the JOB card, we use the XEQ name in the same way the job statement
parameter SCHENV is used, otherwise we let JES2 handle it normally.
The literal /*ROUTE must begin in column 1. The literal XEQ must
follow /*ROUTE, and may be separated by one to twenty blank spaces.
The resource name, if not a valid JES2 node name, must follow the XEQ
literal by between 1 and 35 blank spaces. The resource name can be
between 1 and 16
Re: Controlling the execution sequence of dependant jobs in JES2 (the details)
Ahhh. That would make good sense. Thanks, Dave At 5/23/2008 03:24 PM, Edward Jaffe wrote: David Cole wrote: and it all runs in one batch job Well For a full gen, that would run to somewhere near a thousand steps. Doesn't that blow JES2's JCT limit? (or something like that...) It's sorta' like an SMP/E build. It ATTACHes all of the necessary compilers and utilities from within a single job step. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: A Refreshing Change (Was: switch from CA-SYSVIEW to SDSF)
At 4/24/2008 09:15 AM, McKown, John wrote: World Class? Is that __all__?? From the users, it sounds more like at least Solar class! Maybe even Globular cluster or Galaxy class. Hyper-instellar subspace class? Multiverse class? For the esoteric: Brane-class. It takes a real brain to understand branes. For me, there's no hope. (But they are fun to read about.) Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FW: Workable Mainframe Debuggers
At 4/14/2008 04:57 PM, Tom Ross wrote: By the way, I think IBM has the only debugger for IBM C and C++ on z/OS. Not for much longer. Cheers, TomR COBOL is the Language of the Future! Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 Coming soon: c/XDC for C and C++ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: C++ Workable Mainframe Debuggers
Cole Software's z/XDC - no We are on the verge of publishing C Source code support (c/XDC) to beta testers. More soon. Dave Cole At 4/13/2008 05:53 AM, you wrote: If you're debugging C/C++ on z/OS: 1. There's dbx for UNIX System Services (only): http://www.ibm.com/servers/eserver/zseries/zos/unix/bpxa1dbx.html No charge. 2. IBM Debug Tool for z/OS is available. IBM has introduced a new version annually for years now, so you want to stay current and take a fresh look if you remember an old version. Version 7, in particular, introduced some substantial C++ related improvements. Version 8 is current. I see a lot of old Debug Tool installed out there, unfortunately. You can license Debug Tool as MLC or, in the form of the Debug Tool Utilities Advanced Functions superset product, as OTC with subscription. As you prefer. Unfortunately for z/OS 1.5 you'll be limited to Debug Tool (or DTUAF) Version 7, so please try to get your z/OS release updated as soon as you can, at least for the development LPAR(s) where you're most likely to be debugging. You may be able to work with IBM to order DT or DTUAF Version 8 and arrange temporary use of Version 7; can't hurt to ask. Actually, as I write this Debug Tool V7 MLC is still orderable so no harm there, but for reasons of subscription you'll want to order DTUAF V8 if you go the OTC route. For graphical debugging use Rational Developer for System z (or WebSphere Developer Debugger for System z) in conjunction with Debug Tool (or DTUAF). I think those tools also provide graphical debugging with dbx now. Very slick. A certain popular IBM-MAIN training firm has a course on C/C++ debugging. Details here: http://www.trainersfriend.com/C_courses/N735descr.htm 3. There are a number of commercial debugger products for z/OS, most already mentioned. However, many (all?) of them don't support C++. Here's the latest information I have, and someone please correct me if my information is out of date: Cole Software's z/XDC - no CA-InterTest - no Compuware's Xpediter - C yes, C++ ? Gary Bergman Associates' Advanced Debugging System (ADS) for CICS - C yes, C++ ? Macro4's Tracemaster - no MacKinney Systems' Track and Xray - no ASG's (formerly Viasoft's) SmartTest - no Serena's StarTool ATD - product withdrawn? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
