Re: Accessing USS on Mainframe thru Telnet
I appreciate Chris' knowledge of most things, especially VTAM. But apparently he has a thing about USS. And also appears to believe that if he continues to be bothersome about the misuse of the term USS, that either: (a) people will be educated and will voluntarily change or (b) will become tired of hearing the rants and so change their usage just to shut him up. I doubt that either will occur. IMO, in most cases the meaning of USS is easily recognizable from the context. If it is not, then the email is likely so vague or poorly written that trying to understand what is needed is a waste of my time, and I ignore it. -- 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 Paul Gilmartin Sent: Thursday, April 05, 2012 11:45 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Accessing USS on Mainframe thru Telnet On Thu, 5 Apr 2012 09:31:57 -0500, Chris Mason wrote: However, there are indications you have been seduced by the incorrect use of the abbreviation for what started out as VTAM's Unformatted System Services at least two decades before UNIX System Services appeared on the IBM scene. Don't badger the novice. Vaunting your superiority is unseemly. -- gil -- 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
RAPID
All, I have some old libraries laying around from a product called RAPID. I've never used it or even heard of it before. Apparently the product was de-commissioned before I got here. I believe it is related to Office Vision and/or DISOSS. Who was the vendor? What did it do? What is it's current status i.e. still marketed? The only information I can find is that a company called TBS has a replacement product. Regards, Keith Reynolds System Programmer Shelter Mutual Insurance Company 1817 West Broadway Columbia, Missouri 65218 This e-mail is intended only for its addressee and may contain information that is privileged, confidential, or otherwise protected from disclosure. If you have received this communication in error, please notify us immediately by e-mailing postmas...@shelterinsurance.com; then delete the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Audit SQL Collector
I've been looking through the IBM InfoSphere Guardium S-TAP for DB2 on z/OS manual. In this manual they talk about a Audit SQL Collector (ASC) and that this ASC collects all reads and all changes. Will someone please tell me how the ASC does this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: RAPID
What are the library names? I seem to recall some old serverpac installation verification tests that allocated RAPID1 and RAPID3 dataset or something like that. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Keith Reynolds Sent: Friday, April 06, 2012 8:01 AM To: IBM-MAIN@bama.ua.edu Subject: RAPID All, I have some old libraries laying around from a product called RAPID. I've never used it or even heard of it before. Apparently the product was de-commissioned before I got here. I believe it is related to Office Vision and/or DISOSS. Who was the vendor? What did it do? What is it's current status i.e. still marketed? The only information I can find is that a company called TBS has a replacement product. Regards, Keith Reynolds System Programmer Shelter Mutual Insurance Company 1817 West Broadway Columbia, Missouri 65218 This e-mail is intended only for its addressee and may contain information that is privileged, confidential, or otherwise protected from disclosure. If you have received this communication in error, please notify us immediately by e-mailing postmas...@shelterinsurance.com; then delete the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
So if our navy ever launches a ship called USS VTAM, what type of software would it use? Sorry, it's Friday. ;-) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Friday, April 06, 2012 8:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Accessing USS on Mainframe thru Telnet I appreciate Chris' knowledge of most things, especially VTAM. But apparently he has a thing about USS. And also appears to believe that if he continues to be bothersome about the misuse of the term USS, that either: (a) people will be educated and will voluntarily change or (b) will become tired of hearing the rants and so change their usage just to shut him up. I doubt that either will occur. IMO, in most cases the meaning of USS is easily recognizable from the context. If it is not, then the email is likely so vague or poorly written that trying to understand what is needed is a waste of my time, and I ignore it. -- 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 Paul Gilmartin Sent: Thursday, April 05, 2012 11:45 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Accessing USS on Mainframe thru Telnet On Thu, 5 Apr 2012 09:31:57 -0500, Chris Mason wrote: However, there are indications you have been seduced by the incorrect use of the abbreviation for what started out as VTAM's Unformatted System Services at least two decades before UNIX System Services appeared on the IBM scene. Don't badger the novice. Vaunting your superiority is unseemly. -- gil -- 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: Accessing USS on Mainframe thru Telnet
Probably, given how we do things anymore, it would likely run Windows. I dread the day that we lose a war because our weapons blue screened. -- 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 Tony's Comcast account Sent: Friday, April 06, 2012 8:23 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Accessing USS on Mainframe thru Telnet So if our navy ever launches a ship called USS VTAM, what type of software would it use? Sorry, it's Friday. ;-) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Friday, April 06, 2012 8:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Accessing USS on Mainframe thru Telnet I appreciate Chris' knowledge of most things, especially VTAM. But apparently he has a thing about USS. And also appears to believe that if he continues to be bothersome about the misuse of the term USS, that either: (a) people will be educated and will voluntarily change or (b) will become tired of hearing the rants and so change their usage just to shut him up. I doubt that either will occur. IMO, in most cases the meaning of USS is easily recognizable from the context. If it is not, then the email is likely so vague or poorly written that trying to understand what is needed is a waste of my time, and I ignore it. -- 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 Paul Gilmartin Sent: Thursday, April 05, 2012 11:45 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Accessing USS on Mainframe thru Telnet On Thu, 5 Apr 2012 09:31:57 -0500, Chris Mason wrote: However, there are indications you have been seduced by the incorrect use of the abbreviation for what started out as VTAM's Unformatted System Services at least two decades before UNIX System Services appeared on the IBM scene. Don't badger the novice. Vaunting your superiority is unseemly. -- gil -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: RAPID
Hi Keith, There is likely info in the product libraries, copyright notices, etc. Generally there is info, including the company name and contact info in the install library. The loadlib should have helpful eye catchers in some of the members. Google is often your friend. With what you are likely find in the libraries, you should be able to find the rest, including the info for the current product and vendor, if there is one. HTH, Linda Sent from my iPhone On Apr 6, 2012, at 6:00 AM, Keith Reynolds kreyno...@shelterinsurance.com wrote: All, I have some old libraries laying around from a product called RAPID. I've never used it or even heard of it before. Apparently the product was de-commissioned before I got here. I believe it is related to Office Vision and/or DISOSS. Who was the vendor? What did it do? What is it's current status i.e. still marketed? The only information I can find is that a company called TBS has a replacement product. Regards, Keith Reynolds System Programmer Shelter Mutual Insurance Company 1817 West Broadway Columbia, Missouri 65218 This e-mail is intended only for its addressee and may contain information that is privileged, confidential, or otherwise protected from disclosure. If you have received this communication in error, please notify us immediately by e-mailing postmas...@shelterinsurance.com; then delete the original message. -- 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: RAPID
Rex, The libraries are panels, clist, and loadlib. Regards, Keith Reynolds System Programmer Shelter Mutual Insurance Company 1817 West Broadway Columbia, Missouri 65218 573-214-6506 From: Pommier, Rex R. rex.pomm...@cnasurety.com To: IBM-MAIN@bama.ua.edu Date: 04/06/2012 08:23 AM Subject:Re: RAPID Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu What are the library names? I seem to recall some old serverpac installation verification tests that allocated RAPID1 and RAPID3 dataset or something like that. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Keith Reynolds Sent: Friday, April 06, 2012 8:01 AM To: IBM-MAIN@bama.ua.edu Subject: RAPID All, I have some old libraries laying around from a product called RAPID. I've never used it or even heard of it before. Apparently the product was de-commissioned before I got here. I believe it is related to Office Vision and/or DISOSS. Who was the vendor? What did it do? What is it's current status i.e. still marketed? The only information I can find is that a company called TBS has a replacement product. Regards, Keith Reynolds System Programmer Shelter Mutual Insurance Company 1817 West Broadway Columbia, Missouri 65218 This e-mail is intended only for its addressee and may contain information that is privileged, confidential, or otherwise protected from disclosure. If you have received this communication in error, please notify us immediately by e-mailing postmas...@shelterinsurance.com; then delete the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail is intended only for its addressee and may contain information that is privileged, confidential, or otherwise protected from disclosure. If you have received this communication in error, please notify us immediately by e-mailing postmas...@shelterinsurance.com; then delete the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A deep question about VSAM SHR(4) - can you help?
CICS moderates access to a VSAM file by doing internal CICS-level ENQs. For a KSDS, the ENQ is on the key value. A VSAM dataset in a single CICS region can be used and updated safely my multiple transactions running in that region (or in multiple regions if the file request is sent to a file owning region). Of course, this can lead to a dead lock situation if the transactions try to update multiple records in the same dataset, unless something is done to exclude it. If the VSAM file is local to multiple regions, or between CICS and batch, then you can corrupt the data. If you need concurrent access via batch and CICS, I suggest HW's SYSB product. We use it and it works with no real problems. Basically, SYSB extends CICS' support for Multi Region Option (MRO) access to a dataset to batch. The actual I/O is done in the CICS region. Another post mentioned that two records in the same CI could not undergo update processing at the same time. This is true. However, the current CICS versions use VSAM options such that VSAM returns a indicator on the second request to CICS. And CICS moderates this. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dfhp3c00/4.2.6.1 quote If you do not use VSAM record-level sharing, CICS serializes update requests by base cluster record key. The complete VSAM control interval (CI) containing the requested record is held for exclusive use while an individual command (for example, a READ command with the UPDATE option) is being executed on the record. Once each command is complete, the control interval is released, and only the requested record remains locked. For nonrecoverable data sets, both the VSAM exclusive use and the CICS exclusive use of the record end when the update request is complete in VSAM terms; for example, when the REWRITE command has completed. For recoverable data sets, however, the CICS exclusive use does not end until the task ends or issues a SYNCPOINT command. Recoverability is specified in the data set resource definition. See FILE definition attributes in the CICS Resource Definition Guide for more information about the FILE resource definitions. /quote -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 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® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, 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 Walt Farrell Sent: Thursday, April 05, 2012 6:16 PM To: IBM-MAIN@bama.ua.edu Subject: Re: A deep question about VSAM SHR(4) - can you help? On Thu, 5 Apr 2012 07:16:15 -0700, Mike Kovach mrmach...@yahoo.com wrote: My specific question is this: I want to introduce multi tasking so that 5 copies of the program can update the file concurrently. If we change STRNO(1) to STRNO(5) on the CICS FCT Definition, will VSAM be smart enough to manage the writes to the file so we don't break it and the BATCH still gets the current information? I am not a VSAM expert, nor a CICS expert (nor am I sure whether your program is using CICS functions to write to the data set, or using VSAM macros directly), but I would be concerned about serialization. From DFSMS Using Data Sets at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt 2d4a0/2.7.2.1?SHELF=EZ2ZO213DT=20110606092005 or http://preview.tinyurl.com/76joxao you can read that for SHAREOPTIONS 4 you have the same serialization requirements as for SHAREOPTIONS 3, and for SHAREOPTIONS 3 the book says quote This option requires that the user's program use ENQ/DEQ to maintain data integrity while sharing the data set, including the OPEN and CLOSE processing. User programs that ignore the write integrity guidelines can cause VSAM program checks, lost or inaccessible records, uncorrectable data set failures, and other unpredictable results. This option places responsibility on each user sharing the data set. /quote So unless there's something in CICS issuing appropriate ENQ/DEQ macros, I think you'll need to make some program changes. -- Walt -- 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 /
End of Support for Encryption Key Manager (EKM)
I was on a conference call with an IBM storage specialist yesterday and he mentioned that end of support for EKM is April 2012. I've never seen this statement from IBM, or heard anything about it until that conference call. Can anyone confirm? -- Mark Jacobs Time Customer Service Tampa, FL Learn from yesterday, live for today, hope for tomorrow. The important thing is to not stop questioning. - Albert Einstein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: End of Support for Encryption Key Manager (EKM)
I know that Java 6.0 was the last to have EKM in it. J6.0.1 does not. AFAIK J5.0 still ships with it. -- This email message and any accompanying materials may contain proprietary, privileged and confidential information of CIT Group Inc. or its subsidiaries or affiliates (collectively, CIT), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sen! t from or received at this email address. -- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Jacobs Sent: Friday, April 06, 2012 10:09 AM To: IBM-MAIN@bama.ua.edu Subject: [IBM-MAIN] End of Support for Encryption Key Manager (EKM) I was on a conference call with an IBM storage specialist yesterday and he mentioned that end of support for EKM is April 2012. I've never seen this statement from IBM, or heard anything about it until that conference call. Can anyone confirm? -- Mark Jacobs Time Customer Service Tampa, FL Learn from yesterday, live for today, hope for tomorrow. The important thing is to not stop questioning. - Albert Einstein -- 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
Follow-on to telework article -- query about BYOD
I'm writing for Destination z -- http://destinationz.org/ -- about BYOD (bring your own devices). People describing how they telework mentioned using tablets and smartphones for monitoring work systems, resolving problems, doing routine chores, communicating with colleagues, researching projects, etc. I'd like to hear about specifics -- what's used, in what ways? What can be done and what's still beyond reach? What technology is required inside the organization (mainframe, network, security, etc.) for this to work? What (BYO)devices are best/worst for this? Same for apps? At least as important, what are policies? Do organizations allow using employee-provided gadgets to work inside the trusted network? Do organizations require containerizing authorized applications to prevent contamination by other connections/data/applications? Or is BYOD prohibited? Tolerated? Ignored (head-in-sand management, could happen!) As usual -- thanks for responses! And for extra credit please copy responses to me so I see them outside list digests. -- Gabriel Goldberg, Computers and Publishing, Inc. g...@gabegold.com 3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433 LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Doing a little research on Performance Modeling
If you have MXG, then look for the SOURCLIB dataset. This is where the MXG manual is located (chapter by chapter) and you should find the wonderful details Dr. Merrill put into the MXG code and how things work. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hylton Tom P Sent: Friday, April 06, 2012 7:36 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Doing a little research on Performance Modeling Much to our chagrin, MICS went away about a decade ago. Still have MXG and SAS, and a few others.We do a lot of reporting and lots of system level capacity/hardware planning, just trying to wrap my head around more broad based performance modeling approach on a large project basis: critical path, simulation, forecasting, what/if etc.. Anyone members of acm.org as well as cmg? They had a few special interest groups that seemed worthwhile: SIGMETRICS: http://www.sigmetrics.org/ SIGSIM: http://www.sigsim.org/ SIGMIS: http://www.sigmis.org/ I casually checked into them a few months ago to see about organization memberships and such akin to how Share and IDUG work, but all I could find was a yearly fee for their digital library and it seemed a bit salty so I didn't look much further. But looking, CMG is individual based with yearly fees as well, so maybe I'll have to look again. If you could choose only one for performance modeling , cmg or acm? If you could choose only one for capacity/hardware planning? Thanks again, tom -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Thursday, April 05, 2012 4:41 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Doing a little research on Performance Modeling Tom Do you have SAS and (MICS or MXG)? if so, that is a good starting point. CMG is also a good place to go look for info if you are a member. -- 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: End of Support for Encryption Key Manager (EKM)
I know all that, but we were floored by the statement made by IBM on the call yesterday. I'm trying to get it confirmed. Mark Jacobs On 04/06/12 10:28, Ken Porowski wrote: I know that Java 6.0 was the last to have EKM in it. J6.0.1 does not. AFAIK J5.0 still ships with it. -- This email message and any accompanying materials may contain proprietary, privileged and confidential information of CIT Group Inc. or its subsidiaries or affiliates (collectively, CIT), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications s! en! t from or received at this email address. -- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Jacobs Sent: Friday, April 06, 2012 10:09 AM To: IBM-MAIN@bama.ua.edu Subject: [IBM-MAIN] End of Support for Encryption Key Manager (EKM) I was on a conference call with an IBM storage specialist yesterday and he mentioned that end of support for EKM is April 2012. I've never seen this statement from IBM, or heard anything about it until that conference call. Can anyone confirm? -- Mark Jacobs Time Customer Service Tampa, FL Learn from yesterday, live for today, hope for tomorrow. The important thing is to not stop questioning. - Albert Einstein -- 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 -- Mark Jacobs Time Customer Service Tampa, FL Learn from yesterday, live for today, hope for tomorrow. The important thing is to not stop questioning. - Albert Einstein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Is there a way to cause SRB to TCB percolation if an XCF exit fails?
Hi, XCF has its own recovery. If your message exit recovery fails to field the problem, it percolates to XCF recovery. By default, XCF recovery will always attempt to retry. Since the error was retriable, XCF retried. Thus no SRB to Task percolation occurs. You would need to create a non-retriable error so that XCF itself cannot retry. Is there a need for an interface change here? For example, one might envision a keyword on the IXCJOIN macro that permits the member to indicate that they want SRB to Task percolation to occur if the exit routine fails to field the error. Or perhaps a means for the message exit to tell XCF recovery whether it wants this particular failure to be percolated out to the task. The hard part for the task that gets thumped is that there is no context. As it stands now, when the task recovery gets control it can inspect an abend reason code set by XCF to indicate whether something was lost or not. In the case where something is lost, there is no information as to what the something might have been. That is, with respect to a message exit failure, there is no information about which message was being processed at the time of the failure. Mark A. Brooks z/OS Sysplex design and development 845-435-5149 T/L 8-295-5149 Poughkeepsie, NY mabr...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LE C calling HLASM
Darn it, no matter what I've tried, I CANNOT get PL/I to handle a plist [what I'd call] normally-marking the high bit on the last specified parameter. If I use OPTIONAL, I get all the parameters, with zeroes for the ones that were omitted. That's not right, because I can't tell whether they were omitted or specified as zero. Ideas?? -- ...phsiii Phil Smith III p...@voltage.commailto:p...@voltage.com Voltage Security, Inc. www.voltage.comhttp://www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LE C calling HLASM
On Fri, Apr 6, 2012 at 8:45 AM, Phil Smith p...@voltage.com wrote: Darn it, no matter what I've tried, I CANNOT get PL/I to handle a plist [what I'd call] normally-marking the high bit on the last specified parameter. If I use OPTIONAL, I get all the parameters, with zeroes for the ones that were omitted. That's not right, because I can't tell whether they were omitted or specified as zero. Ideas?? When using OPTIONAL, isn't the address in the parmlist set to zero instead of a valid address? Said differently, if the address in the parmlist is zero, the associated parameter is not available. -- ...phsiii Phil Smith III p...@voltage.commailto:p...@voltage.com Voltage Security, Inc. www.voltage.comhttp://www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- 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: LE C calling HLASM
On 4/6/2012 9:53 AM, Sam Siegel wrote: On Fri, Apr 6, 2012 at 8:45 AM, Phil Smithp...@voltage.com wrote: Darn it, no matter what I've tried, I CANNOT get PL/I to handle a plist [what I'd call] normally-marking the high bit on the last specified parameter. If I use OPTIONAL, I get all the parameters, with zeroes for the ones that were omitted. That's not right, because I can't tell whether they were omitted or specified as zero. Ideas?? When using OPTIONAL, isn't the address in the parmlist set to zero instead of a valid address? Said differently, if the address in the parmlist is zero, the associated parameter is not available. But his dilema is that in C data itself may be passed in the parmlist; now the dilema: is a pointer of zeros (address of parm is NULL) an indicator of an omitted argument or a deliberate pass of a value of zeros. There is no magic way for anyone to know: you have to establish conventions and protocols to make these distinctions. And with the latest compilers this conundrum exists in Assembler, COBOL, PL/I and C. Adding flexibility always comes at a price of added complexity or potential ambiguity (or both), right? -- ...phsiii Phil Smith III p...@voltage.commailto:p...@voltage.com Voltage Security, Inc. www.voltage.comhttp://www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- 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 -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LE C calling HLASM
On Fri, Apr 6, 2012 at 9:02 AM, Steve Comstock st...@trainersfriend.comwrote: On 4/6/2012 9:53 AM, Sam Siegel wrote: On Fri, Apr 6, 2012 at 8:45 AM, Phil Smithp...@voltage.com wrote: Darn it, no matter what I've tried, I CANNOT get PL/I to handle a plist [what I'd call] normally-marking the high bit on the last specified parameter. If I use OPTIONAL, I get all the parameters, with zeroes for the ones that were omitted. That's not right, because I can't tell whether they were omitted or specified as zero. Ideas?? When using OPTIONAL, isn't the address in the parmlist set to zero instead of a valid address? Said differently, if the address in the parmlist is zero, the associated parameter is not available. But his dilema is that in C data itself may be passed in the parmlist; now the dilema: is a pointer of zeros (address of parm is NULL) an indicator of an omitted argument or a deliberate pass of a value of zeros. There is no magic way for anyone to know: you have to establish conventions and protocols to make these distinctions. And with the latest compilers this conundrum exists in Assembler, COBOL, PL/I and C. True - I missed that point. Thanks for the correction. Adding flexibility always comes at a price of added complexity or potential ambiguity (or both), right? -- ...phsiii Phil Smith III p...@voltage.commailto:phil@**voltage.com p...@voltage.com Voltage Security, Inc. www.voltage.comhttp://www.**voltage.com http://www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) --**--** -- 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 -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/**ROI/roi.htmlhttp://www.trainersfriend.com/ROI/roi.html --**--**-- 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: A z/OS Redbook Corrected - just about!
In order not to disturb those delicate souls who can't take too much of this topic, I have consolidated my responses. --- From Sebastian Welton Wed, 21 Mar 2012 10:48:13 -0500 ... then maybe IBM will have to change ***all*** their manuals. Obviously untrue! Of the 400 plus manuals in the z/OS elements and features bookshelves[1], about 40 are contaminated. Thus I'll allow an order of magnitude of 10 percent as a general estimate overall. It is not an infeasible objective to have essentially corrected with a bit of effort. Where the incorrect use appears, it, in effect, corresponds to John Eells's stray cats and they tend to appear in ones and twos in most manuals. In other words, it is never systematic. Looking back over some releases I have noticed some new text with a stray cat get herded back after an edition or two. I'll admit it doesn't happen every time and there a bit of work to be done. Thank you for the reminder that not all the contagion is to be found on the z/OS elements and features bookshelves and that contagion is more likely when the origin of the manual is the untrammelled domain of previously vendor products. Confusion could abound for the novice ... Indeed it could but, more likely, inevitably will. That is the major concern I try to emphasise but the noisy ones ignore. ... but I'm pretty sure that if someone sees: ... they are going to know what the book is discussing. That's as may be. But when someone saw quote Someone got the uss screen, was able to get into the production CICS, /quote he demonstrated he completely misunderstood what the post was discussing. Or let me take an invented example: But when someone sees invented quote Use an USS command to access the application. If you made a mistake, you will be able to see from the USS message returned what your mistake was. /invented quote and the reader has had no prior contact with this correct usage - for which the manual author may justifiably have felt no need whatsoever for a so-called clarification - they are *not* going to know what the book is discussing and they are going to be all at sea! Your confused novice may well have his or her eyes opened eventually with a bit of a shock when, because of downsizing, the old SNA/VTAM specialist is retired to the golf course and this novice is expected to take over. I've seen it happen. Fortunately I know there was a manager who could admit to dealing with it if necessary - his userid was on the ancient source files! - [1] http://www-03.ibm.com/systems/z/os/zos/bkserv/zshelves13.html --- From Kirk Wolf Wed, 21 Mar 2012 10:57:58 -0500 Thank goodness IBM is spending time correcting USS atrocities rather than improving z/OS Unix. Compensating for the sarcasm, I imagine the correction took about half an hour if my opposite experience over *re*introducing the correct abbreviation into the IBM z/OS V1Rxx Communications Server TCP/IP Implementation set of manuals a while ago is anything to go by. These computer thingamajigs are pretty good at this sort of thing! Incidentally ITSO is not in the business of actually improving products - that's development. ITSO have the responsibility to advise on how to use products, typically in combination, and provide background, tutorials and the like. --- From Rob Schramm Wed, 21 Mar 2012 12:07:00 -0400 I know that only a very short list of people will ever be truly confused by USS (unformatted system services) and USS (unix system services) references How can you possibly know anything of the sort! Even among IBM-MAIN subscribers we generally hear only from the spittle-flecked brigade on this topic - although I'm encouraged by some who have put their heads above the parapet and risked the slings and arrows of the outraged in order to express agreement. Try - hard this time - to understand the response above to Sebastian Walton. --- From Dick Bond Mon, 26 Mar 2012 10:16:32 -0700 I agree with Chris Mason. Thank you! IBM should have never started called it USS ... In principle - as John Eells explained to Eric Bielefeld who made the same assertion - IBM never did. It was careless IBM employees - starting - if the manuals I have tracked are anything to go by - with one author in one manual of three in the German development lab prior even to the name change from OpenEdition to UNIX System Services. IBM adores putting a z in front of everything (for some clueless reason) ... There's no accounting for the ideas suits get into their heads! Actually in a way, there is: if a suit pays for some marketing advice, it is likely to be introduced - because it was paid for, no matter how ridiculous. In MBA courses, this tendency is discouraged, but I guess the message doesn't always get through. --- From Mark Zelden Mon, 26 Mar 2012 13:21:56 -0500 but USS started long before z was ever around. Approximately a quarter of a century, from 1977 to 2001[1]. BTW, I still see
Re: Accessing USS on Mainframe thru Telnet
On 4/6/2012 6:09 AM, McKown, John wrote: I appreciate Chris' knowledge of most things, especially VTAM. But apparently he has a thing about USS. And also appears to believe that if he continues to be bothersome about the misuse of the term USS, that either: (a) people will be educated and will voluntarily change or (b) will become tired of hearing the rants and so change their usage just to shut him up. I chose option (c). ;-) -- 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: End of Support for Encryption Key Manager (EKM)
I know all that, but we were floored by the statement made by IBM on the call yesterday. I'm trying to get it confirmed. Mark Jacobs I was on a conference call with an IBM storage specialist yesterday and he mentioned that end of support for EKM is April 2012. I've never seen this statement from IBM, or heard anything about it until that conference call. Can anyone confirm? -- Mark Jacobs Time Customer Service Tampa, FL Mark, I think that IBM is being obtuse on this issue. We hear just bits and pieces and slowly see the process going away. I have no confirmation of EOS. However, from this list I know that any JAVA from 1.6.0.1 and above EKM is gone. If you hold onto the JAVA 1.6.0 or 1.5 then you can continue to run EKM. I have not seen or heard any specific details that EKM is no longer supported. I think they still do it if pushed. I agree that IBM should be upfront and say what their intent is, rather than making the user community fret. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
Edward I chose option (c). That'll be don't misuse the abbreviation in the first place and use it only for the IBM context for which it was first coined - I suppose. Chris Mason On Fri, 6 Apr 2012 09:31:32 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: On 4/6/2012 6:09 AM, McKown, John wrote: ... (a) people will be educated and will voluntarily change or (b) will become tired of hearing the rants and so change their usage just to shut him up. ... I chose option (c). ;-) -- Edward E Jaffe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
Get a life! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Friday, April 06, 2012 12:45 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Accessing USS on Mainframe thru Telnet Edward I chose option (c). That'll be don't misuse the abbreviation in the first place and use it only for the IBM context for which it was first coined - I suppose. Chris Mason On Fri, 6 Apr 2012 09:31:32 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: On 4/6/2012 6:09 AM, McKown, John wrote: ... (a) people will be educated and will voluntarily change or (b) will become tired of hearing the rants and so change their usage just to shut him up. ... I chose option (c). ;-) -- Edward E Jaffe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: RAPID
Hi Keith, If you will Google disoss rapid software there are a bunch of 'hits'. HTH, Linda - Original Message - From: Keith Reynolds kreyno...@shelterinsurance.com To: IBM-MAIN@bama.ua.edu Sent: Friday, April 6, 2012 6:38:22 AM Subject: Re: RAPID Rex, The libraries are panels, clist, and loadlib. Regards, Keith Reynolds System Programmer Shelter Mutual Insurance Company 1817 West Broadway Columbia, Missouri 65218 573-214-6506 From: Pommier, Rex R. rex.pomm...@cnasurety.com To: IBM-MAIN@bama.ua.edu Date: 04/06/2012 08:23 AM Subject: Re: RAPID Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu What are the library names? I seem to recall some old serverpac installation verification tests that allocated RAPID1 and RAPID3 dataset or something like that. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Keith Reynolds Sent: Friday, April 06, 2012 8:01 AM To: IBM-MAIN@bama.ua.edu Subject: RAPID All, I have some old libraries laying around from a product called RAPID. I've never used it or even heard of it before. Apparently the product was de-commissioned before I got here. I believe it is related to Office Vision and/or DISOSS. Who was the vendor? What did it do? What is it's current status i.e. still marketed? The only information I can find is that a company called TBS has a replacement product. Regards, Keith Reynolds System Programmer Shelter Mutual Insurance Company 1817 West Broadway Columbia, Missouri 65218 This e-mail is intended only for its addressee and may contain information that is privileged, confidential, or otherwise protected from disclosure. If you have received this communication in error, please notify us immediately by e-mailing postmas...@shelterinsurance.com; then delete the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail is intended only for its addressee and may contain information that is privileged, confidential, or otherwise protected from disclosure. If you have received this communication in error, please notify us immediately by e-mailing postmas...@shelterinsurance.com; then delete the original message. -- 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: Accessing USS on Mainframe thru Telnet
John ... he appears to believe that if he continues to be bothersome about the misuse of the term USS, ... Did you not notice the extreme provocation which led to last month's post? One of the redbook authors actually had the temerity to claim that the misuse was official! Since my riposte referred to some IBM-MAIN traffic - in addition to the consolidation of the reasons why it was so wrong - it seemed only polite to pass on the text to the subscribers. IMO, in most cases the meaning of USS is easily recognizable from the context. Most is not all. And it is in the difference between most and all that the *immediate* ambiguity/confusion can arise. In these cases, as in this thread, TELNET will be involved. For novices, the problem is a delayed ambiguity. As I'm sure I've said recently, probably more than once, a novice will become bamboozled with the repeated misuse and will suffer when and if presented with the genuine article in an easily imagined scenario. Howard Rifkind - bless him - is the living - I hope - proof! It is, of course, so totally unnecessary since IBM in its wisdom back when it was decided to change OpenEdition to UNIX System Services so thoughtfully provided the abbreviation OS/390 UNIX - which naturally needed to morph into z/OS UNIX - which incidentally, even under provocation, you adopt. If it is not, then the email is likely so vague or poorly written that trying to understand what is needed is a waste of my time, and I ignore it. It's also not too easy what you are trying to say here. It has the aura of a bit of a wriggle! Finally, if I have reason to participate in a thread and the post to which I am replying contains the misuse, I reserve the right - against all the rants of the spittle-flecked[2] - to insert a correction, if only to maintain credibility! - Anyhow I'm pleased that your efforts and mine and Mark Zelden's probably provided Chokalingam Thangavelu with all he needed to know. - [1] I hope he forgives the reference but it so precisely illustrates my point and he was brave enough to express his confusion. I expect many another has suffered - and will suffer - in silence. Thread: Mainframe hacking Date: Mon, 20 Jul 2009 05:36:28 -0700 [2] If there's any ranting going on, it is inevitably the spittle-flecked who start it and I feel obliged to respond in kind in order to give no possibility of credence to the falsehoods expressed. In the case you quoted, it was the Gilmartin character - and I didn't even get round to rubbishing the total lack of logic in his final comment. - Chris Mason On Fri, 6 Apr 2012 08:09:53 -0500, McKown, John john.mck...@healthmarkets.com wrote: I appreciate Chris' knowledge of most things, especially VTAM. But apparently he has a thing about USS. And also appears to believe that if he continues to be bothersome about the misuse of the term USS, that either: (a) people will be educated and will voluntarily change or (b) will become tired of hearing the rants and so change their usage just to shut him up. I doubt that either will occur. IMO, in most cases the meaning of USS is easily recognizable from the context. If it is not, then the email is likely so vague or poorly written that trying to understand what is needed is a waste of my time, and I ignore it. -- John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
Garrulousity personified On Fri, 6 Apr 2012 12:48:02 -0400, Veilleux, Jon L veilleu...@aetna.com wrote: Get a life! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LE C calling HLASM
Is there a reliable way to tell we were called by PL/I? If so, we could ignore zeroes for PL/I. And document it. ISTR there being a magic fullword in the savearea for PL/I? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
I prefer to keep my comments succinct rather than ramble on about inane complaints about acronym usage. You must have too much time on your hands to waste so much of it on useless bickering, ergo, you need to get a life. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Friday, April 06, 2012 1:28 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Accessing USS on Mainframe thru Telnet Garrulousity personified On Fri, 6 Apr 2012 12:48:02 -0400, Veilleux, Jon L veilleu...@aetna.com wrote: Get a life! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: openssl make - z/OS UNIX question - Help
Thanks Kirk, Originally I opened this thread to the MVS-OE but got no response which is why I enter to IBM-MAIN. Here are my results. It looks much better after your suggested changes, I think... I see RC4_CHUNK is undefined Not sure if this is an issue or not and what it actually means to me. So after 10 or so screens worth of: for all the directories. gmakeÝ1¨: Entering directory `/u/w012108/temp/openssl-1.0.1/ssl' ssl.h = ../include/openssl/ssl.h ssl2.h = ../include/openssl/ssl2.h ssl3.h = ../include/openssl/ssl3.h ssl23.h = ../include/openssl/ssl23.h tls1.h = ../include/openssl/tls1.h dtls1.h = ../include/openssl/dtls1.h kssl.h = ../include/openssl/kssl.h srtp.h = ../include/openssl/srtp.h ssltest.c = ../test/ssltest.c gmakeÝ1¨: Leaving directory `/u/w012108/temp/openssl-1.0.1/ssl' I finally get Configured for os/compiler. Now heres where my knowledge drops off even more.. If that possible when it comes to this. What do I do now, How to I get a new openssl module built? Thanks Ms. Terri E. Shaffer terri.e.shaf...@jpmchase.com Engineer J.P.Morgan Chase Co. GTI DCT ECS Core Services zSoftware Group / Emerging Technologies Office: # 614-213-3467 Cell: # 412-519-2592 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Kirk Wolf Sent: Thursday, April 05, 2012 2:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: openssl make - z/OS UNIX question - Help Terri - try this running config in test mode. This is what I get for OpenSSL 0.9.8q: ./config -t Operating system: 2094-whatever-OS/390 Configuring for OS/390 /usr/lpp/perl/bin/perl ./Configure OS/390 So far so good. I assume you will get something similar, except your machine is a 2817. Why does it say OS/390? Because that's still how z/OS refers to itself in output from the uname command. Now, see if the Configure perl script supports OS/390 perl ./Configure LIST | grep OS/390 I assume that this will be missing on 1.0.1, which would explain the error that you are getting. If this is the case, what does it mean? It means that no one has done the porting and testing for configuring the build for z/OS with OpenSSL 1.0.1. In 0.9.8q Configure, you will find this: # OS/390 Unix an EBCDIC-based Unix system on IBM mainframe # You need to compile using the c89.sh wrapper in the tools directory, because the # IBM compiler does not like the -L switch after any object modules. # OS390-Unix,c89.sh:-O -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE::(unknown):::THIRTY_TWO_BIT DES_PTR DES_UNROLL MD2_CHAR RC4_INDEX RC4_CHAR BF_PTR:::, When I last ported 0.9.8q, I modified this to read: *OS/390*,*xlc*:-O -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H * -Wc,xplink* -D_ALL_SOURCE::*::-Wl,xplink*:THIRTY_TWO_BIT DES_PTR DES_UNROLL MD2_CHAR RC4_INDEX RC4_CHAR BF_PTR:::, Note that I chose to use XPLINK. I found that the c89.sh wrapper wasn't required if I used the xlc command and exported C89_CCMODE=1 as described earlier. You might also consider adding LANGLVL, ARCH, and TUNE compiler options, depending on what you are doing. Its been a while, but I seem to remember submitting this patch upstream. So, you are going to have to probably make the same patch to the 1.0.1 Configure perl script. But there could be differences in the format of this (very complicated) line. Finally, I would suggest that you probably want to move this thread to the mvs...@vm.marist.edu list. Regards, Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Apr 4, 2012 at 8:56 AM, Shaffer, Terri E terri.e.shaf...@jpmchase.com wrote: Hi Kirk, Okay that changed the world for the better, I now have the file in the right format. Onto the next issue now.. W012108:SDEV(DEV):/u/w012108/temp/openssl-1.0.1 ./config --prefix=/u/w012108/o penssl --openssldir=/u/w012108/openssl $MAKE Operating system: 2817-whatever-OS/390 This system (OS/390) is not supported. See file INSTALL for details. W012108:SDEV(DEV):/u/w012108/temp/openssl-1.0.1 What I did I do this time? Is this correct for z/OS Unix? Is there a solution? Thanks Ms. Terri E. Shaffer terri.e.shaf...@jpmchase.com Engineer J.P.Morgan Chase Co. GTI DCT ECS Core Services zSoftware Group / Emerging Technologies Office: # 614-213-3467 Cell: # 412-519-2592 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Kirk Wolf Sent: Wednesday, April 04, 2012 8:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: openssl make - z/OS UNIX question - Help So, your files are still in ASCII on z/OS? You may need Gil to help with that :-) Try unwinding the tarball into EBCDIC files:
Re: Accessing USS on Mainframe thru Telnet
John, Frankly I've never understood Chris's problem with USS, except that he may suffer from some sort of OCD reaction when he sees those letters. We all know that USS stands for Unix System Services, and any other employment of the acronym with the Mainframe community should spell out that it is not using this accepted, commonplace, default meaning. VTAM Unformatted System Services is one good example, where authors should discipline themselves to explain that they are not referring to Unix System Services rather than confusing everyone by hijacking this acronym. And as for naming boats, how would HMAS ever get confused with USS? Is this the appropriate place for the :-) Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Friday, April 06, 2012 6:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Accessing USS on Mainframe thru Telnet I appreciate Chris' knowledge of most things, especially VTAM. But apparently he has a thing about USS. And also appears to believe that if he continues to be bothersome about the misuse of the term USS, that either: (a) people will be educated and will voluntarily change or (b) will become tired of hearing the rants and so change their usage just to shut him up. I doubt that either will occur. IMO, in most cases the meaning of USS is easily recognizable from the context. If it is not, then the email is likely so vague or poorly written that trying to understand what is needed is a waste of my time, and I ignore it. -- 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 Paul Gilmartin Sent: Thursday, April 05, 2012 11:45 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Accessing USS on Mainframe thru Telnet On Thu, 5 Apr 2012 09:31:57 -0500, Chris Mason wrote: However, there are indications you have been seduced by the incorrect use of the abbreviation for what started out as VTAM's Unformatted System Services at least two decades before UNIX System Services appeared on the IBM scene. Don't badger the novice. Vaunting your superiority is unseemly. -- gil -- 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: Accessing USS on Mainframe thru Telnet
http://en.wikipedia.org/wiki/USS_Yorktown_(CG-48) On 21 September 1997, while on maneuvers off the coast of Cape Charles, Virginia, a crew member entered a zero into a database field causing a divide by zero error in the ship's Remote Data Base Manager which brought down all the machines on the network, causing the ship's propulsion system to fail.[5] [deleted[ Atlantic Fleet officials also denied the towing, reporting that Yorktown was dead in the water for just 2 hours and 45 minutes.[6] [deleted] On Fri, Apr 6, 2012 at 8:32 AM, McKown, John john.mck...@healthmarkets.com wrote: Probably, given how we do things anymore, it would likely run Windows. I dread the day that we lose a war because our weapons blue screened. -- John McKown Systems Engineer IV -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
No amount of discussion has or will ever quell this battle. Declare your own victory and do as I have: a) Don't use USS to refer to z/OS Unix System Services b) Don't correct someone who does c) Filter emails from Chris Mason. A pity that 5% of his voluminous posts are valuable, but not worth the rest. Unfortunately, there isn't an official acronym for z/OS Unix System Services. Until such time as there is, maybe we should use zUSS or maybe Xeus :-) Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Apr 6, 2012 at 12:50 PM, Veilleux, Jon L veilleu...@aetna.comwrote: I prefer to keep my comments succinct rather than ramble on about inane complaints about acronym usage. You must have too much time on your hands to waste so much of it on useless bickering, ergo, you need to get a life. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
Well, possibly to the relief of all, I will hencefore ignore any and all posts to this forum which include the letters USS which do not also explicitly say UNIX or VTAM. I'm simply to old and tired to bother any more. In this particular thread, I will agree that USS could be confusing since telnet could refer to either accessing a z/OS UNIX shell prompt via historic telnet, or to accessing an LU2 VTAM application via TN3270E which is also a special encoded 3270 data stream using the telnet protocol. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
USS plus useful content - Read fully USS acronym wars --Plonk! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: USS YORKTOWN(was Accessing USS on Mainframe thru Telnet)
It's hard for me to imagine the navy allowing itself to get into a situation where the operation of the ship's main engines and steering would be completely subject to some PC, or number of PC's on a network within the ship. I put just shy of 3yrs. in an engine room aboard a navy ship, back in the 1960's. The ship had redundancy built into practically every piece of equipment that was needed to maintain steerage, even down to manual pumps to pump hydraulic fluid thru the steering gear. If you are dead in the water, you are a sitting duck. They just don't build 'em like that. They may have waited some period of time before going to manual systems to get underway, but I doubt seriously if a network crash would would have prevented complete movement. --Dave On 4/6/2012 1:54 PM, Mike Schwab wrote: http://en.wikipedia.org/wiki/USS_Yorktown_(CG-48) On 21 September 1997, while on maneuvers off the coast of Cape Charles, Virginia, a crew member entered a zero into a database field causing a divide by zero error in the ship's Remote Data Base Manager which brought down all the machines on the network, causing the ship's propulsion system to fail.[5] [deleted[ Atlantic Fleet officials also denied the towing, reporting that Yorktown was dead in the water for just 2 hours and 45 minutes.[6] [deleted] On Fri, Apr 6, 2012 at 8:32 AM, McKown, John john.mck...@healthmarkets.com wrote: Probably, given how we do things anymore, it would likely run Windows. I dread the day that we lose a war because our weapons blue screened. -- John McKown Systems Engineer IV -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
Kirk Wolf: Unfortunately, there isn't an official acronym for z/OS Unix System Services. Until such time as there is, maybe we should use zUSS or maybe Xeus :-) Since you insisted: http://www-03.ibm.com/systems/z/os/zos/features/unix/ Regards, Steve Thompson Opinions expressed by this poster do not necessarily reflect those of poster's employer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
On 4/6/2012 1:18 PM, Steve Thompson wrote: Kirk Wolf: Unfortunately, there isn't an official acronym for z/OS Unix System Services. Until such time as there is, maybe we should use zUSS or maybe Xeus :-) Since you insisted: http://www-03.ibm.com/systems/z/os/zos/features/unix/ Regards, Steve Thompson And if you click on the 'Education' tab ... -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
LU0, SNA, TCPIP issue
Scenario: CICS application-LU0 SNA (OSA Eth)HIS-Windows APP Server-WinClients In other words there is a CICS based application, which is cuurently accessed via LU0 terminals. The application server (windows based) is connected to the host via HIS, formerly known as MS SNA Server. So, from the network point of view Windows machine is connected to the mainframe using SNA protocol. We want to get rid of the HIS. So, we would like to use LU0 and TCP/IP communication. Note: we're aware of Enterprise Extender, but our goal is to get rid of HIS. As far as now I just set up dedicated (for LU0) telnet server with his own port. Any ideas, comments, prompts are welcome. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LU0, SNA, TCPIP issue
Lots of ways to go here. Upgrade CICS to use LU2. CICS also (IIRC) speaks TCP directly. TN3270/TN3270E Some emulator client on PC (Rumba, VISTA, PCOMM) HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: openssl make - z/OS UNIX question - Help
Sounds to me like config/Configure worked (and generated make files). Refer to my original response: -- configure and make ./config --prefix=/usr/local --openssldir=/usr/local/openssl export _C89_CCMODE=1 export MAKE=gmake $MAKE so, do the exports and then execute gmake ($MAKE) Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Apr 6, 2012 at 1:05 PM, Shaffer, Terri E terri.e.shaf...@jpmchase.com wrote: Thanks Kirk, Originally I opened this thread to the MVS-OE but got no response which is why I enter to IBM-MAIN. Here are my results. It looks much better after your suggested changes, I think... I see RC4_CHUNK is undefined Not sure if this is an issue or not and what it actually means to me. So after 10 or so screens worth of: for all the directories. gmakeÝ1¨: Entering directory `/u/w012108/temp/openssl-1.0.1/ssl' ssl.h = ../include/openssl/ssl.h ssl2.h = ../include/openssl/ssl2.h ssl3.h = ../include/openssl/ssl3.h ssl23.h = ../include/openssl/ssl23.h tls1.h = ../include/openssl/tls1.h dtls1.h = ../include/openssl/dtls1.h kssl.h = ../include/openssl/kssl.h srtp.h = ../include/openssl/srtp.h ssltest.c = ../test/ssltest.c gmakeÝ1¨: Leaving directory `/u/w012108/temp/openssl-1.0.1/ssl' I finally get Configured for os/compiler. Now heres where my knowledge drops off even more.. If that possible when it comes to this. What do I do now, How to I get a new openssl module built? Thanks Ms. Terri E. Shaffer terri.e.shaf...@jpmchase.com Engineer J.P.Morgan Chase Co. GTI DCT ECS Core Services zSoftware Group / Emerging Technologies Office: # 614-213-3467 Cell: # 412-519-2592 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Kirk Wolf Sent: Thursday, April 05, 2012 2:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: openssl make - z/OS UNIX question - Help Terri - try this running config in test mode. This is what I get for OpenSSL 0.9.8q: ./config -t Operating system: 2094-whatever-OS/390 Configuring for OS/390 /usr/lpp/perl/bin/perl ./Configure OS/390 So far so good. I assume you will get something similar, except your machine is a 2817. Why does it say OS/390? Because that's still how z/OS refers to itself in output from the uname command. Now, see if the Configure perl script supports OS/390 perl ./Configure LIST | grep OS/390 I assume that this will be missing on 1.0.1, which would explain the error that you are getting. If this is the case, what does it mean? It means that no one has done the porting and testing for configuring the build for z/OS with OpenSSL 1.0.1. In 0.9.8q Configure, you will find this: # OS/390 Unix an EBCDIC-based Unix system on IBM mainframe # You need to compile using the c89.sh wrapper in the tools directory, because the # IBM compiler does not like the -L switch after any object modules. # OS390-Unix,c89.sh:-O -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE::(unknown):::THIRTY_TWO_BIT DES_PTR DES_UNROLL MD2_CHAR RC4_INDEX RC4_CHAR BF_PTR:::, When I last ported 0.9.8q, I modified this to read: *OS/390*,*xlc*:-O -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H * -Wc,xplink* -D_ALL_SOURCE::*::-Wl,xplink*:THIRTY_TWO_BIT DES_PTR DES_UNROLL MD2_CHAR RC4_INDEX RC4_CHAR BF_PTR:::, Note that I chose to use XPLINK. I found that the c89.sh wrapper wasn't required if I used the xlc command and exported C89_CCMODE=1 as described earlier. You might also consider adding LANGLVL, ARCH, and TUNE compiler options, depending on what you are doing. Its been a while, but I seem to remember submitting this patch upstream. So, you are going to have to probably make the same patch to the 1.0.1 Configure perl script. But there could be differences in the format of this (very complicated) line. Finally, I would suggest that you probably want to move this thread to the mvs...@vm.marist.edu list. Regards, Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Apr 4, 2012 at 8:56 AM, Shaffer, Terri E terri.e.shaf...@jpmchase.com wrote: Hi Kirk, Okay that changed the world for the better, I now have the file in the right format. Onto the next issue now.. W012108:SDEV(DEV):/u/w012108/temp/openssl-1.0.1 ./config --prefix=/u/w012108/o penssl --openssldir=/u/w012108/openssl $MAKE Operating system: 2817-whatever-OS/390 This system (OS/390) is not supported. See file INSTALL for details. W012108:SDEV(DEV):/u/w012108/temp/openssl-1.0.1 What I did I do this time? Is this correct for z/OS Unix? Is there a solution? Thanks Ms. Terri E. Shaffer terri.e.shaf...@jpmchase.com Engineer J.P.Morgan Chase Co. GTI DCT ECS Core Services zSoftware Group / Emerging Technologies Office: # 614-213-3467 Cell: # 412-519-2592 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Kirk Wolf Sent: Wednesday,
Re: LU0, SNA, TCPIP issue
W dniu 2012-04-06 21:54, Staller, Allan pisze: Lots of ways to go here. Upgrade CICS to use LU2. CICS also (IIRC) speaks TCP directly. TN3270/TN3270E Some emulator client on PC (Rumba, VISTA, PCOMM) The goal is to get rid of HIS and not to make any revolution. It also means to stay with LU0 (application understand LU0). BTW:The client application is NOT 3270 emulator, it is our own GUI based client, which talks to the windows server application which in turn talks to mainframe (via HIS). I think it would be enough to change last layer of the application which talks to HIS and simply set up telnet server on host side. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: USS YORKTOWN(was Accessing USS on Mainframe thru Telnet)
I came into work one morning and the office was staring out my window into San Francisco Bay. The Carl Vincent had run aground trying to return to it's berth at Alameda Naval Air Station. All the Crowley tugs were pushing and pulling, but they finally had to wait for a 'high tide' about 36 hrs. Long story short the Captain had ordered the pilot to proceed-during the court marshal was relieved of command. Hundreds of thousands to clean and recertify the props and impellers. In a message dated 4/6/2012 3:25:08 P.M. Central Daylight Time, david...@consolidated.net writes: It's hard for me to imagine the navy allowing itself to get into a situation where the operation of the ship's main engines and steering would be completely -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SLIP PER Sotroage Alteration SVC dump
Hi, I just got a hit and generated an SVC dump from a SLIP Storage Alteration My memory sort of escapes me on what IPCS option I would find the culprit that caused the storage overlay From memory I do believe it would be one of the IPCS traces if someone could help I would appreciate it Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: USS YORKTOWN(was Accessing USS on Mainframe thru Telnet)
Yea, running one of 'em aground is a big no-no for a captains career. --Dave On 4/6/2012 3:34 PM, Ed Finnell wrote: I came into work one morning and the office was staring out my window into San Francisco Bay. The Carl Vincent had run aground trying to return to it's berth at Alameda Naval Air Station. All the Crowley tugs were pushing and pulling, but they finally had to wait for a 'high tide' about 36 hrs. Long story short the Captain had ordered the pilot to proceed-during the court marshal was relieved of command. Hundreds of thousands to clean and recertify the props and impellers. In a message dated 4/6/2012 3:25:08 P.M. Central Daylight Time, david...@consolidated.net writes: It's hard for me to imagine the navy allowing itself to get into a situation where the operation of the ship's main engines and steering would be completely -- 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: SLIP PER Sotroage Alteration SVC dump
Either use STATUS REGS which shows the PSW and REGS when the slip trapped, or look at the contents of the SDUMP CSA resident buffer (CVTSDBUF) which has data on the state of the system when the slip trap hit. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Micheal Butz michealb...@optonline.net To: IBM-MAIN@bama.ua.edu Date: 04/06/2012 03:42 PM Subject: SLIP PER Sotroage Alteration SVC dump Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hi, I just got a hit and generated an SVC dump from a SLIP Storage Alteration My memory sort of escapes me on what IPCS option I would find the culprit that caused the storage overlay From memory I do believe it would be one of the IPCS traces if someone could help I would appreciate it Thanks -- 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: SLIP PER Sotroage Alteration SVC dump
THANKS -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Wayne Driscoll Sent: Friday, April 06, 2012 4:55 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SLIP PER Sotroage Alteration SVC dump Either use STATUS REGS which shows the PSW and REGS when the slip trapped, or look at the contents of the SDUMP CSA resident buffer (CVTSDBUF) which has data on the state of the system when the slip trap hit. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Micheal Butz michealb...@optonline.net To: IBM-MAIN@bama.ua.edu Date: 04/06/2012 03:42 PM Subject: SLIP PER Sotroage Alteration SVC dump Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hi, I just got a hit and generated an SVC dump from a SLIP Storage Alteration My memory sort of escapes me on what IPCS option I would find the culprit that caused the storage overlay From memory I do believe it would be one of the IPCS traces if someone could help I would appreciate it Thanks -- 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: Accessing USS on Mainframe thru Telnet
Ron When were you born? Was it in 1997 or 1977? If it was 1997, you would now be 20 years older than if it was 1977 - according to your logic. Frankly I've never understood Chris's problem with USS, ... Now you know! Chris Mason P.S. Please take the trouble actually to read through the initial post of the still active thread A z/OS Redbook Corrected - just about!, Wed, 21 Mar 2012 07:34:55 -0500. On Fri, 6 Apr 2012 11:54:33 -0700, Ron Hawkins ronjhawk...@sbcglobal.net wrote: John, Frankly I've never understood Chris's problem with USS, except that he may suffer from some sort of OCD reaction when he sees those letters. We all know that USS stands for Unix System Services, and any other employment of the acronym with the Mainframe community should spell out that it is not using this accepted, commonplace, default meaning. VTAM Unformatted System Services is one good example, where authors should discipline themselves to explain that they are not referring to Unix System Services rather than confusing everyone by hijacking this acronym. ... Ron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LE C calling HLASM
many years ago I needed to know, in DOS/VS, whether an assembler routine was called from a PL/I or assembler module. I put in a test to see if in DOS terms the weak extrn PLIMAIN was not 0. Non zero meant a PL/I module was present. Ken On 7/04/2012 03:46 AM, Phil Smith wrote: Is there a reliable way to tell we were called by PL/I? If so, we could ignore zeroes for PL/I. And document it. ISTR there being a magic fullword in the savearea for PL/I? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Ken Mob: 0409 009 764 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Acroymn Usage
My understanding of the correct use of ANY acromyn in academic papers is that you write out the topic in full then in put the acromyn in brackets. Then every one reading the paper knows what the acromyn refers too. -- Ken Mob: 0409 009 764 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Enterprise COBOL and XML attributes
Enterprise COBOL v4.2. First real world attempt at using XML GENERATE. Works as designed, and relatively user friendly, but not particularly flexible for real world requirements. XML GENERATE will generate no fields as attributes unless with WITH ATTRIBUTES phrase is specified. In that case it will generate attributes (rather than elements) ANYWHERE it can. I just want to make sure, before I go any further, that there is ABSOLUTELY NO WAY, using just XML GENERATE, that some fields that COULD be attributes can not be forced to be elements if the WITH ATTRIBUTES phrase is specified. For example, I cannot generate the following using XML GENERATE alone (no post-processing to modify the generated XML document): underwritingrequest crossSellOfferId12000/crossSellOfferId channelTypeWEB-IA/channelType offerCategoryConsumer/offerCategory preApprovedProds product categoryCode=CC limit=5000/ product categoryCode=CR limit=1000/ /preApprovedProds parties party dob01/01/1950/dob scoreNo725298/scoreNo income10/income housingExpense1200/housingExpense housingStatusOwns/housingStatus /party /parties /underwritingrequest As you can see, all of the elementary data items are XML elements EXCEPT for the categoryCode and limit fields under product. Current COBOL group data item: 01 underwritingrequest. 05 crossSellOfferId pic x(10). 05 channelType pic x(10). 05 preApprovedProds. 10 product. 15 categoryCode pic x(2). 15 l1mit pic 9(7). 05 parties. 10 party occurs 1 to 10 times depending on party-count indexed by p_idx. 15 dob pic 99/99/. 15 scoreNo pic 9(9). 15 income pic 9(9). 15 housingExpense pic 9(9). 15 housingStatus pic x(10). Please note that I have seen the tech note XML GENERATE should create attributes under COBOL; http://www-01.ibm.com/support/docview.wss?uid=swg21218516 All I can say is (to quote Seth Meyers and Amy Poehler): Really?!?! Since we own the process that consumes this XML document I hope I can convince them to go either all attributes or all elements, but not this little mish-mash. But I want to make sure I am not missing something SIMPLE that I can do to get what they really want. (I already have to change use field name '1imit' instead of 'limit' and then do INSPECT UWR-DOC REPLACING ALL l1mit BY limit, because LIMIT is a COBOL reserved word. Oy!) some short time later Ah hah, here's a trick. I don't love it, but I can perhaps live with it. I can specific OCCURS 1 for any field that I want to be an element rather than an attribute: 01 underwritingrequest. 05 crossSellOfferId pic x(10) occurs 1. 05 channelType pic x(10) occurs 1. 05 preApprovedProds. 10 product. 15 categoryCode pic x(2). 15 l1mit pic 9(7). 05 parties. 10 party occurs 1 to 10 times depending on party-count indexed by p_idx. 15 dob pic 99/99/ occurs 1. 15 scoreNo pic 9(9) occurs 1. 15 income pic 9(9) occurs 1. 15 housingExpense pic 9(9) occurs 1. 15 housingStatus pic x(10) occurs 1. Funky, but it works. Of course I now have to use a subscript qualification (or an extra one, in the case of the party children. Oh well! If there's a better way I'd still like to know, but at least I got it to work. Thanks! Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LE C calling HLASM
On 4/6/2012 5:23 PM, Ken Brick wrote: many years ago I needed to know, in DOS/VS, whether an assembler routine was called from a PL/I or assembler module. I put in a test to see if in DOS terms the weak extrn PLIMAIN was not 0. Non zero meant a PL/I module was present. Ken On 7/04/2012 03:46 AM, Phil Smith wrote: Is there a reliable way to tell we were called by PL/I? If so, we could ignore zeroes for PL/I. And document it. ISTR there being a magic fullword in the savearea for PL/I? Well, you could maybe do the same thing about the PL/I LE signature CSECT, CEESG011. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Acroymn Usage
Yes. Except when the (possibly ambiguous) acronym *is* the topic. ;-) Now, since it's not only Friday but, in fact, the only Good Friday . . . 1) Are you dyslexic? In four instances of the word, you spelled acronym two different ways, neither of them correct. 2) Any resemblance between postings on IBM-MAIN and academic papers is purely coincidental. === . Date: Sat, 7 Apr 2012 09:14:42 +1000 From: kbr...@netspace.net.au Subject: Acroymn Usage To: IBM-MAIN@bama.ua.edu My understanding of the correct use of ANY acromyn in academic papers is that you write out the topic in full then in put the acromyn in brackets. Then every one reading the paper knows what the acromyn refers too. -- Ken Mob: 0409 009 764 -- 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
hosting for something small
I am looking for some place to host tomcat running jspwiki on z/OS. Possibly to provide a home for software porting for free utilities. Of course I would like to do it economically... but I would like to eat my own food so to speak. Anyone have any ideas? I'd like to figure out a way to make it self sufficient. Rob Schramm Senior Systems Consultant Imperium Group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: hosting for something small
Rob: Contact me. I may have a place for you. What is the size, scope, utilization,. access method required, etc.? Mitch -Original Message- From: Rob Schramm rob.schr...@gmail.com To: IBM-MAIN IBM-MAIN@bama.ua.edu Sent: Fri, Apr 6, 2012 5:35 pm Subject: hosting for something small I am looking for some place to host tomcat running jspwiki on z/OS. Possibly to provide a home for software porting for free utilities. Of course I would like to do it economically... but I would like to eat my own food so to speak. Anyone have any ideas? I'd like to figure out a way to make it self sufficient. Rob Schramm Senior Systems Consultant Imperium Group -- 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: Accessing USS on Mainframe thru Telnet
Hook, line, and sinker... -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Friday, April 06, 2012 3:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Accessing USS on Mainframe thru Telnet Ron When were you born? Was it in 1997 or 1977? If it was 1997, you would now be 20 years older than if it was 1977 - according to your logic. Frankly I've never understood Chris's problem with USS, ... Now you know! Chris Mason P.S. Please take the trouble actually to read through the initial post of the still active thread A z/OS Redbook Corrected - just about!, Wed, 21 Mar 2012 07:34:55 -0500. On Fri, 6 Apr 2012 11:54:33 -0700, Ron Hawkins ronjhawk...@sbcglobal.net wrote: John, Frankly I've never understood Chris's problem with USS, except that he may suffer from some sort of OCD reaction when he sees those letters. We all know that USS stands for Unix System Services, and any other employment of the acronym with the Mainframe community should spell out that it is not using this accepted, commonplace, default meaning. VTAM Unformatted System Services is one good example, where authors should discipline themselves to explain that they are not referring to Unix System Services rather than confusing everyone by hijacking this acronym. ... Ron -- 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: Accessing USS on Mainframe thru Telnet
John, For the most part I agree with you, except in the first line of his actual post, the original poster made it quite obvious to anybody which of the two USS's he was referring to, which makes this current argument all the more stupid. I think this whole thing is painfully silly, as Mr. Mason will never give up on his crusade to stop anybody from using USS to refer to Unix stuff, and a few others seem to take delight in needling him on, and the vast majority of us would prefer the whole thing just dry up. No amount of cajoling will get either side to change their respective minds, but unfortunately apparently no amount of begging them to just give it up will make that happen either. And it's too bad, because I have been the recipient on a couple occasions of some of Mr. Mason's wisdom in regards to a VTAM issue that I was having. Unfortunately the gems get lost in the bickering. Like you, this will be my last (and in my case my first) post on the subject. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Friday, April 06, 2012 2:03 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Accessing USS on Mainframe thru Telnet Well, possibly to the relief of all, I will hencefore ignore any and all posts to this forum which include the letters USS which do not also explicitly say UNIX or VTAM. I'm simply to old and tired to bother any more. In this particular thread, I will agree that USS could be confusing since telnet could refer to either accessing a z/OS UNIX shell prompt via historic telnet, or to accessing an LU2 VTAM application via TN3270E which is also a special encoded 3270 data stream using the telnet protocol. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A z/OS Redbook Corrected - just about!
Chris, I took your advice and read this post, but then I took it to a higher authority for validation. Yes, I googled acronym USS.' Mate, I'm sure I don't have to tell you that the internet holds the keys that unlock all mysteries, and for this one I was horrified to find that for all your hard work, the first hit in Google just simply did not support your position. There was the site with all the answers staring me in the face, waiting for the USS conundrum to be unraveled at a hit labeled USS - Definition by AcronymFinder. I mean, this has to be place to find the correct meaning of an acronym - forget all these red books and stuff. And so I curtailed my googling activities, sallied forth, clicked my mouse button, and infiltrated this place of purveyance to negotiate the reading of some contracted comestibles. And there it was, on the fifth line of the list: Unix System Services (IBM). I'm afraid there was no mention of that other meaning you are always talking about. I mean, based on this unassailable reference it is hard to believe that Unformatted System Services was ever abbreviated to USS, and probably should not have been because all the math's majors working in mainframes back then would have immediately been misled into thinking one was talking about the Uncorrected Sum of Squares (did you know that SAS has a USS function - you should write to them and get them to change it). So I'm afraid we have Internet 1, Chris nil, and we should all start using USS the way God and Google intended us to. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Wednesday, March 21, 2012 5:35 AM To: IBM-MAIN@bama.ua.edu Subject: [IBM-MAIN] A z/OS Redbook Corrected - just about! Back in early February, I sent off this comment to the redbooks site: comment To whom it may concern, - This feedback concerns redbook z/OS Version 1 Release 13 Implementation, SG24-7946-00, which is described still to be in Draft status. - Recently I wanted to check on what z/OSMF was all about. Expecting to be more quickly enlightened by finding a suitable redbook, I tried z/OSMF as a search word on the redbooks site. There were 3 hits, the first, gratifyingly, was entitled z/OS Management Facility. The other two were z/OS Version 1 Release xx Implementation, where xx was 12 and 13. I happened to notice the following at the beginning of the z/OS UNIX System Services chapter in the release 13 redbook: quote z/OS UNIX System Services, is an element of z/OS, is a UNIX operating environment, and is implemented within the z/OS operating system. It is also known as z/OS UNIX. In addition, there is a short abbreviation called USS. /quote How very curious, I thought. How did this mistake creep in? I then checked the beginning of the z/OS UNIX System Services chapter in the release 12 redbook and found that the curious addition had been slipped in only in the later V1R13 edition: quote The UNIX System Services element of z/OS is a UNIX operating environment, implemented within the z/OS operating system. It is also known as z/OS UNIX. /quote Since the V1R13 redbook is still in draft status, the inappropriate text can be removed. - First, in order to confirm that the abbreviation sanctioned by the authors of the manuals when UNIX System Services was introduced, we can pick any of the front-line manuals, the OS/390 MVS Initialization and Tuning Reference being one: quote CHANGES Summary of Changes ... As part of the name change of OS/390 OpenEdition to OS/390 UNIX System Services, occurrences of OS/390 OpenEdition have been changed to OS/390 UNIX System Services or its abbreviated name, OS/390 UNIX. ... /quote http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/IEA1E211/CHANGES Thus we have it confirmed that OS/390 UNIX is the supported abbreviation, clearly to be transformed to z/OS UNIX when z/OS was introduced and that there is nary a mention of any other abbreviation. After all, one abbreviation should be sufficient, shouldn't it? In case there is any doubt over the ancestry of this other abbreviation, we have the following web page in order to remind us what, within IBM, is the correct attribution: http://www- 01.ibm.com/software/globalization/terminology/u.html#x2042481 quote IBM Terminology ... This site contains terms and definitions from many IBM software and hardware products as well as general computing terms. ... unformatted system service (USS) A communications function that translates a character-coded command, such as a LOGON or LOGOFF command, into a field-formatted command for processing by formatted system services. See also formatted system service. ... USS See unformatted system service. ... /quote Now there are some - particularly to be found in the IBM-MAIN list - who will swear that
