Re: Simple VTAM-Question?
For your TN3270 server you don't need to cycle the server, just refresh the profile. Any new connections will pick up the new USS table. V TCPIP,TN3270,O,PROFILE.DATA.SET For VTAM, use the following F NET,TABLE,OPTION=LOAD,NEWTAB=TABNAME Earl Michael Knigge [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 10/15/2008 04:01 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Simple VTAM-Question? All, I've modified my VTAM Logon Screen and now want to activate it. Is this possible without an IPL? I guess I have to do a F LLA,REFRESH and then to restart the TN3270-Server. But what do I have to do for the real 3270-Terminals? Restart VTAM? How? Thank you - guess it is a simple question for VTAM-Guys but I'm pretty new in this area Bye, Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TN3270 port change
Scott, Try this. Logon to tso on that lpar and from a ready prompt enter TELNET xx.xx.xx.xx 1234 and see if you can connect. That will tell you if the TN3270 server is functioning on that port. You might also turn on debug in the TN3270 server. Earl Scott Ford [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 09/17/2008 11:13 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject TN3270 port change Hi all, I just migrated from z/OS 1.6 to z/OS 1.9. My question is as follows: Our 1.6 system used a port other than 23 for TN3270 sessions. The port also was a non-secure port. I tried the sane methodology, i.e.; changed port 23 to port 1234 ( example ) in TCPIP profile and the TN3270 address space STC parms. I see TN3270 listening but can't connect..what am I missing. I tried inside our firewall and outside. I also noticed, I cannot ping the z/OS system or can't ping the Ethernet segement it is attached... Thanks in advance... Scott IDF -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OBEYFILE Question
You can unreserve those ports by creating a member named DELPORTS with the following (where xx is the name in your existing profile where you have the ports reserved). Use obeyfile against your ipstack, pointing to DELPORTS. DELETE PORT 5150 TCP xxx DELETE PORT 2112 TCP xxx You can P/S TN3270 to cycle the task. Earl Dean Montevago [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 09/08/2008 10:57 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: OBEYFILE Question Hi, We just migrated to z/OS 1.9. I have two ports reserved for use with the IBM Debug Tool, ports 5150 and 2112 in my TCPIP profile. I had this defined from z/OS 1.7. When TN3270 starts I am getting bind errors for these ports RC=6F. I am thinking that since they are reserved in the TCPIP profile when TN3270 starts it can't bind on these. I specify these ports in the TELNET section of my TN3270 member. I want to unreserve these ports. Can I do it with an OBEYFILE command against the TCPIP address space ? Also, can the TN3270 address space be cancelled and restarted ? or do you use a P command against it. Where are the rules documented regarding reserving a port and not reserving one. I am thinking if it's hardcoded you don't reserve it like in this case, where no one would be able to dynaically select it. Please advise (Can you sense a bit of panic?). TIA Dean Dean Montevago Sr. Systems Specialist Visiting Nurse Service of New York (212) 609 - 9608 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP from windows to z/os error code 451
Your error is caused by quote mode b. Is block mode supported between windows and z/OS ? Earl Gilbert Cardenas [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 07/24/2008 06:02 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject FTP from windows to z/os error code 451 Hello all, I am trying to FTP an LCDS type file from a windows server to a z/OS 1.7 mainframe and then submit jcl to print that dataset using iebgener however, I keep getting the following error : 451 Error error closing the data set. File is catalogued. Explanation: The MVS data set did not close successfully. The data set was catalogued. error is not meaningful. System action: FTP continues processing. User response: Change the CONDDISP setting with a SITE subcommand if you do not want data sets to be catalogued when file transfers fail. See the z/OS Communications Server: IP User's Guide and Commands for information about the SITE subcommand. System programmer response: None. Here are the commands I am passing : quote mode b quote type e quote site recfm=vbm put c:\tmp\META2113 'META2113.LCDS.FILE' quote mode s quote type a quote site recfm=fb lrecl=80 blksize=27920 quote site filetype=jes site jeslrecl=80 put c:\tmp\FTP.JCL.2113 bye quit I am verifying that the mainframe file is not cataloged prior to the ftp so the message is somewhat misleading. Any ideas/suggestions would be appreciated. Best regards, Gil. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
When they achieve zero down time will the name change to z/IBMLink ? Earl Edward Jaffe [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 07/19/2008 08:15 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO Patrick O'Keefe wrote: And look at the subject line again. Note the lower case is. Not all CAPs. There is still room for serious escallation here. The extent to which further escalation is possible all depends on what your definition of is is. ;-) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCPIP Segmentation Offload
So how do you control the the offload on the individual OSAs ? By issuing an OBEYFILE on a different profile and then issuing a stop/start on the device ? Earl Zimmerman, Tom [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 06/09/2008 02:11 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: TCPIP Segmentation Offload We have segmentation offload, microcode level 087D, running on eight of our OSAs for the last two weeks. We have eight LPARs, each with one tcpip stack. Each stack has two OSAs connected to it, with one running segmentation offlad and the other without it. It will be some time in JULY before I start segmentation offload on the second OSA. Tom Zimmerman -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Maarten Slegtenhorst Sent: Sunday, June 08, 2008 3:48 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: TCPIP Segmentation Offload John, /quote/ We enabled SEGMENTATIONOFFLOAD on the sandbox (z/OS 1.9) yesterday, but there's very little TCPIP load on the sandbox (still doing IVP of 1.9, and post-installation cleanup). Maybe we can cobble up something that should stress it to the breaking point (maybe FTP-ing some SMF offload datasets or sysdumps?). /quote/ We have a load of about 10% on the OSA's and still the segmentation offload managed to crash both shared osa's and managed to make most production-hosts unreachable. Of course this happened during the night in my standby week. :/ I wont activate it until I'm convinced that the risk of the same problems occuring is very very very small. -- Maarten Slegtenhorst - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -Message Disclaimer- This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email to [EMAIL PROTECTED] and delete or destroy all copies of the original message and attachments thereto. Email sent to or from the Principal Financial Group or any of its member companies may be retained as required by law or regulation. Nothing in this message is intended to constitute an Electronic signature for purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic Signatures in Global and National Commerce Act (E-Sign) unless a specific statement to the contrary is included in this message. While this communication may be used to promote or market a transaction or an idea that is discussed in the publication, it is intended to provide general information about the subject matter covered and is provided with the understanding that The Principal is not rendering legal, accounting, or tax advice. It is not a marketed opinion and may not be used to avoid penalties under the Internal Revenue Code. You should consult with appropriate counsel or other advisors on all matters pertaining to legal, tax, or accounting obligations and requirements. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained
Re: TCPIP Segmentation Offload
Does your sandbox share OSAs with production lpars? When we encountered the problem with offload, every lpar sharing the OSA was impacted. Earl Chase, John [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 06/06/2008 11:18 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: TCPIP Segmentation Offload -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Peterson This morning, I checked the Exception Letters for our z9 and z10 processors. Both Exception Letters are dated May 28, 2008, and both still say that Segmentation Offload needs to be disabled. I am not saying that IBM hasn't fixed the problem - I hope they have. But, the Exception Letters still say the problem is NOT fixed. Interesting They're dated three days LATER than the date we installed the latest ucode (that was supposed to fix the problem). We enabled SEGMENTATIONOFFLOAD on the sandbox (z/OS 1.9) yesterday, but there's very little TCPIP load on the sandbox (still doing IVP of 1.9, and post-installation cleanup). Maybe we can cobble up something that should stress it to the breaking point (maybe FTP-ing some SMF offload datasets or sysdumps?). Meanwhile, we'll leave it disabled on the other LPARs until we hear something more reassuring (or determine that we can't break it on the sandbox). -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
