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 10/15/2008 04:01 PM Please respond to IBM Mainframe Discussion List 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 09/17/2008 11:13 AM Please respond to IBM Mainframe Discussion List 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 09/08/2008 10:57 AM Please respond to IBM Mainframe Discussion List 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 07/24/2008 06:02 PM Please respond to IBM Mainframe Discussion List 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 07/19/2008 08:15 AM Please respond to IBM Mainframe Discussion List 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
06/09/2008 02:11 PM
Please respond to
IBM Mainframe Discussion List
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 in this e-mail is strictly prohi
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 06/06/2008 11:18 AM Please respond to IBM Mainframe Discussion List 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
Earl K. Buhrmester/Winchester/DST/US is out of the office.
I will be out of the office starting 05/23/2008 and will not return until 05/27/2008. - 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
