Error handeling (Was: How to stop PIPE STARMON)
Hello Rob, Are you sure this will work in all cases? The SIGNAL ON ERROR will react to any non-zero returncode. STREAMSTATE ca n have returncodes 0, 4 and 8, and it looks to me that all three are acceptable, at least in my case. Only rc=12, stream not connected, is indeed the returncode I will trigger upon. But the SIGNAL ON ERROR will exit the stage in all returncodes other than zero. But more in general, there are more commands that will exit a returncode based on their function. WAKEUP for instance. Just a small test confirms this: signal on error 'wakeup +00:30 (cons' say rc error: exit rc The result is that wakeup will return rc=2 when the timer expires and 6 when the console interrupt is received. In both cases valid returncodes, or perhaps required returncodes, but in both cases the SIGNAL traps the 'error' and skips the SAY rc command. In such cases it looks like errorhandeling should be coded for every individual event instead of a general error handeling trap. Regards, Berry. On Mon, 9 Jun 2008 21:38:15 +0200, Rob van der Heij [EMAIL PROTECTED] wrote: signal on error do forever peekto .. process.. readto streamstate output end error: return rc * ( rc 12 )
Re: SFS Control Data Backup
The QIUCV EXEC level I have reports in part (edited to remove lots of unrelated info, but leaving at least one line of each message type, and all our SFS-related servers): qiucv Path Target CP System Target MsgMsg Path Path ID Userid Service PathID Limit Count Flags Type --- OPERATOR *MSG 00FF C0IUCV ...deleted lines... S$SFCRR1 *BLOCKIO 0010 D0IUCV 0001 S$SFCRR1 *BLOCKIO 00010010 D0IUCV 0002 S$SFCRR1 *BLOCKIO 00020010 D0IUCV 0003 S$SFCRR1 *BLOCKIO 00030010 D0IUCV 0004 S$SFCRR1 *BLOCKIO 00040010 D0IUCV 0005 S$SFCRR1 *BLOCKIO 00050010 D0IUCV 0006 S$SFCRR1 *BLOCKIO 00060010 D0IUCV 0007 VMSERVS *BLOCKIO 0010 D0IUCV 0008 VMSERVS *BLOCKIO 00010010 D0IUCV 0009 VMSERVS *BLOCKIO 00020010 D0IUCV 000A VMSERVS *BLOCKIO 00030010 D0IUCV 000B VMSERVS *BLOCKIO 00040010 D0IUCV 000C S$SFACT1 *BLOCKIO 0042 D0IUCV 000D S$SFGEN1 *BLOCKIO 0081 D0IUCV 000E S$SFGEN1 *BLOCKIO 00010081 D0IUCV 000F S$SFGEN1 *BLOCKIO 00020081 D0IUCV 0010 S$SFPCS1 *BLOCKIO 0010 D0IUCV 0011 S$SFACT1 *BLOCKIO 00010042 D0IUCV 0012 S$SFACT1 *BLOCKIO 00020042 D0IUCV 0013 S$SFACT1 *BLOCKIO 00030042 D0IUCV 0014 S$SFACT1 *BLOCKIO 00040042 D0IUCV 0015 S$SFACT1 *BLOCKIO 00050042 D0IUCV 0016 S$SFACT1 *BLOCKIO 00060042 D0IUCV 0017 S$SFACT1 *BLOCKIO 00070042 D0IUCV 0018 S$SFACT1 *BLOCKIO 00080042 D0IUCV 0019 S$SFACT1 *BLOCKIO 00090042 D0IUCV 001A S$SFACT1 *BLOCKIO 000A0042 D0IUCV 001B S$SFPCS1 *BLOCKIO 00010010 D0IUCV 001C S$SFPCS1 *BLOCKIO 00020010 D0IUCV 001D S$SFGEN1 *BLOCKIO 00030081 D0IUCV 001E S$SFGEN1 *BLOCKIO 00040081 D0IUCV 001F S$SFGEN1 *BLOCKIO 00050081 D0IUCV 0020 S$SFGEN1 *BLOCKIO 00060081 D0IUCV 0021 S$SFAUD1 *BLOCKIO 0042 D0IUCV 0022 S$SFPCS1 *BLOCKIO 00030010 D0IUCV 0023 S$SFPCS1 *BLOCKIO 00040010 D0IUCV 0024 S$SFPCS1 *BLOCKIO 00050010 D0IUCV 0025 S$SFPCS1 *BLOCKIO 00060010 D0IUCV 0026 S$SFPCS1 *BLOCKIO 00070010 D0IUCV 0027 S$SFPCS1 *BLOCKIO 00080010 D0IUCV 0029 S$SFPCS1 *BLOCKIO 000A0010 D0IUCV 002A S$SFPCS1 *BLOCKIO 000B0010 D0IUCV 002B S$SFPCS1 *BLOCKIO 000C0010 D0IUCV 002C S$SFPCS1 *BLOCKIO 000D0010 D0IUCV 002D S$SFPCS1 *BLOCKIO 000E0010 D0IUCV 002E S$SFPPS1 *BLOCKIO 0061 D0IUCV 002F S$SFPPS1 *BLOCKIO 00010061 D0IUCV 0030 S$SFPPS1 *BLOCKIO 00020061 D0IUCV 0031 S$SFPPS1 *BLOCKIO 00030061 D0IUCV 0032 S$SFPPS1 *BLOCKIO 00040061 D0IUCV 0033 S$SFPPS1 *BLOCKIO 00050061 D0IUCV 0034 S$SFGEN1 *BLOCKIO 00070081 D0IUCV 0035 S$SFGEN1 *BLOCKIO 00080081 D0IUCV 0036 S$SFPPS1 *BLOCKIO 00060061 D0IUCV 0037 S$SFPPS1 *BLOCKIO 00070061 D0IUCV 0038 S$SFAUD1 *BLOCKIO 00010042 D0IUCV 0039 S$SFAUD1 *BLOCKIO 00020042 D0IUCV 003A S$SFAUD1 *BLOCKIO 00030042 D0IUCV 003B S$SFAUD1 *BLOCKIO 00040042 D0IUCV ...deleted lines... VMSECURE *RPI 00013E80 0003 C0IUCV ESAWRITE *MONITOR 0001003C D0IUCV GCS *SIGNAL00FF D0IUCV ...deleted lines... TCPIP*CCS 000A E0IUCV ...deleted lines... OPERSYMP *SYMPTOM 000A C0IUCV VMACCT *ACCOUNT 000A C0IUCV EREP *LOGREC000A C0IUCV SYSTEM *IDENT 00FF C0IUCV 0001 S$SFCRR1 *IDENT 000700FF C0IUCV 0002 S$SFCRR1 *IDENT 000800FF C0IUCV 0003 S$SFCRR1 *IDENT 000900FF C0IUCV 0004 S$SFCRR1 *IDENT 000A00FF C0IUCV 0005 S$SFCRR1 *IDENT 000B00FF C0IUCV 0006 VMSERVS *IDENT 000500FF C0IUCV 0007 S$SFPPS1 *IDENT 000800FF C0IUCV 0008 S$SFGEN1 *IDENT 000900FF C0
Re: SFS Control Data Backup
Q IUCV can't help in this case, Q FILEPOOL AGENT has more info: you can see who is active in SFS at that instance; with Q IUCV one can only see who made some connection with SFS since his IPL CMS (once connected to an SFS server, one remains connected). An IUCV report with -by user- counts of IUCV traffic could help to find who's sending/getting much data to/from SFS. 2008/6/11 Mike Walter [EMAIL PROTECTED]: The QIUCV EXEC level I have reports in part (edited to remove lots of unrelated info, but leaving at least one line of each message type, and all our SFS-related servers): qiucv Path Target CP System Target MsgMsg Path Path ID Userid Service PathID Limit Count Flags Type --- OPERATOR *MSG 00FF C0IUCV ...deleted lines... S$SFCRR1 *BLOCKIO 0010 D0IUCV 0001 S$SFCRR1 *BLOCKIO 00010010 D0IUCV 0002 S$SFCRR1 *BLOCKIO 00020010 D0IUCV 0003 S$SFCRR1 *BLOCKIO 00030010 D0IUCV 0004 S$SFCRR1 *BLOCKIO 00040010 D0IUCV 0005 S$SFCRR1 *BLOCKIO 00050010 D0IUCV 0006 S$SFCRR1 *BLOCKIO 00060010 D0IUCV 0007 VMSERVS *BLOCKIO 0010 D0IUCV 0008 VMSERVS *BLOCKIO 00010010 D0IUCV 0009 VMSERVS *BLOCKIO 00020010 D0IUCV 000A VMSERVS *BLOCKIO 00030010 D0IUCV 000B VMSERVS *BLOCKIO 00040010 D0IUCV 000C S$SFACT1 *BLOCKIO 0042 D0IUCV 000D S$SFGEN1 *BLOCKIO 0081 D0IUCV 000E S$SFGEN1 *BLOCKIO 00010081 D0IUCV 000F S$SFGEN1 *BLOCKIO 00020081 D0IUCV 0010 S$SFPCS1 *BLOCKIO 0010 D0IUCV 0011 S$SFACT1 *BLOCKIO 00010042 D0IUCV 0012 S$SFACT1 *BLOCKIO 00020042 D0IUCV 0013 S$SFACT1 *BLOCKIO 00030042 D0IUCV 0014 S$SFACT1 *BLOCKIO 00040042 D0IUCV 0015 S$SFACT1 *BLOCKIO 00050042 D0IUCV 0016 S$SFACT1 *BLOCKIO 00060042 D0IUCV 0017 S$SFACT1 *BLOCKIO 00070042 D0IUCV 0018 S$SFACT1 *BLOCKIO 00080042 D0IUCV 0019 S$SFACT1 *BLOCKIO 00090042 D0IUCV 001A S$SFACT1 *BLOCKIO 000A0042 D0IUCV 001B S$SFPCS1 *BLOCKIO 00010010 D0IUCV 001C S$SFPCS1 *BLOCKIO 00020010 D0IUCV 001D S$SFGEN1 *BLOCKIO 00030081 D0IUCV 001E S$SFGEN1 *BLOCKIO 00040081 D0IUCV 001F S$SFGEN1 *BLOCKIO 00050081 D0IUCV 0020 S$SFGEN1 *BLOCKIO 00060081 D0IUCV 0021 S$SFAUD1 *BLOCKIO 0042 D0IUCV 0022 S$SFPCS1 *BLOCKIO 00030010 D0IUCV 0023 S$SFPCS1 *BLOCKIO 00040010 D0IUCV 0024 S$SFPCS1 *BLOCKIO 00050010 D0IUCV 0025 S$SFPCS1 *BLOCKIO 00060010 D0IUCV 0026 S$SFPCS1 *BLOCKIO 00070010 D0IUCV 0027 S$SFPCS1 *BLOCKIO 00080010 D0IUCV 0029 S$SFPCS1 *BLOCKIO 000A0010 D0IUCV 002A S$SFPCS1 *BLOCKIO 000B0010 D0IUCV 002B S$SFPCS1 *BLOCKIO 000C0010 D0IUCV 002C S$SFPCS1 *BLOCKIO 000D0010 D0IUCV 002D S$SFPCS1 *BLOCKIO 000E0010 D0IUCV 002E S$SFPPS1 *BLOCKIO 0061 D0IUCV 002F S$SFPPS1 *BLOCKIO 00010061 D0IUCV 0030 S$SFPPS1 *BLOCKIO 00020061 D0IUCV 0031 S$SFPPS1 *BLOCKIO 00030061 D0IUCV 0032 S$SFPPS1 *BLOCKIO 00040061 D0IUCV 0033 S$SFPPS1 *BLOCKIO 00050061 D0IUCV 0034 S$SFGEN1 *BLOCKIO 00070081 D0IUCV 0035 S$SFGEN1 *BLOCKIO 00080081 D0IUCV 0036 S$SFPPS1 *BLOCKIO 00060061 D0IUCV 0037 S$SFPPS1 *BLOCKIO 00070061 D0IUCV 0038 S$SFAUD1 *BLOCKIO 00010042 D0IUCV 0039 S$SFAUD1 *BLOCKIO 00020042 D0IUCV 003A S$SFAUD1 *BLOCKIO 00030042 D0IUCV 003B S$SFAUD1 *BLOCKIO 00040042 D0IUCV ...deleted lines... VMSECURE *RPI 00013E80 0003 C0IUCV ESAWRITE *MONITOR 0001003C D0IUCV GCS *SIGNAL00FF D0IUCV ...deleted lines... TCPIP*CCS 000A E0IUCV ...deleted lines... OPERSYMP *SYMPTOM 000A C0IUCV VMACCT *ACCOUNT 000A C0IUCV EREP *LOGREC000A C0IUCV SYSTEM *IDENT 00FF C0IUCV 0001 S$SFCRR1 *IDENT 000700FF C0
Re: Printing a TRSOURCE/IPFORMAT Trace
Hi Dick, The 'formatted' IPFORMAT data file (file type IPFDATA) is packed with the PIPE PACK stage. If you process this file with the PIPE UNPACK stage, you 'll have a flat file that contains all of the formatted packet data (after th e packet 'summary') in a more legible form, that you can edit, print as needed... The Pipe below will create suh a flat file: pipe tracex ipfdata a | unpack | tracex prtdata a The various formatted packets are prefixed using a Pn marker string. Regarding the (un?) ordered display of selected packets , this could be d ue to a bug in the code. If you'd like to pursue that further, just open a PMR with the support center... Regards, Mark Cibula, IBM z/VM Systems Management
Re: Error handeling (Was: How to stop PIPE STARMON)
In that case, insert signal off error before and signal on error after the streamstate. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Berry van Sleeuwen Sent: Wednesday, June 11, 2008 3:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Error handeling (Was: How to stop PIPE STARMON) Hello Rob, Are you sure this will work in all cases? The SIGNAL ON ERROR will react to any non-zero returncode. STREAMSTATE ca= n have returncodes 0, 4 and 8, and it looks to me that all three are acceptable, at least in my case. Only rc=12, stream not connected, is = indeed the returncode I will trigger upon. But the SIGNAL ON ERROR will = exit the stage in all returncodes other than zero. But more in general, there are more commands that will exit a returncode = based on their function. WAKEUP for instance. Just a small test confirms = this: signal on error 'wakeup +00:30 (cons' say rc error: exit rc The result is that wakeup will return rc=2 when the timer expires and 6= when the console interrupt is received. In both cases valid returncodes, = or perhaps required returncodes, but in both cases the SIGNAL traps the 'error' and skips the SAY rc command. In such cases it looks like errorhandeling should be coded for every individual event instead of a general error handeling trap. Regards, Berry. On Mon, 9 Jun 2008 21:38:15 +0200, Rob van der Heij [EMAIL PROTECTED] = wrote: signal on error do forever peekto .. process.. readto streamstate output end error: return rc * ( rc 12 )
Re: Question for old-timers
We're going to be retiring soon-I'm first :-D Are you sure of that? (The I'm first bit, that is.) :-) Regards, Richard Schuh
Defining Devices
How do I change a device that partially emulates a 3480 from supported to unsupported without an ipl? I presume that the command SET RDEVICE TYPE UNSUP DEVCLASS TAPE would be needed. Would this need to be preceded by the command SET RDEVICE CLEAR? Would having the device OFFLINE before entering the command(s) be sufficient? Regards, Richard Schuh
Re: Question for old-timers
I expect to be leaving, at least from full time work, sometime in August. I do expect to work part time from home, since I hardly ever have to touch the real computer, so I'm not going to be quite retired. I love being a VM sysprog and don't want to just logoff one day and never see a VM logo again. I couldn't take the withdrawal. Jim Schuh, Richard wrote: We're going to be retiring soon-I'm first :-D =20 Are you sure of that? (The I'm first bit, that is.) :-)=20 Regards,=20 Richard Schuh=20 =20 =20 -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Defining Devices
How do I change a device that partially emulates a 3480 from supported to unsupported without an ipl? I presume that the command SET RDEVICE TYPE UNSUP DEVCLASS TAPE would be needed. Would this need to be preceded by the command SET RDEVICE CLEAR? Would having the device OFFLINE before entering the command(s) be sufficient?=20 You shouldn't need SET RDEVICE CLEAR, but the device must be varied offline before you issue SET RDEVICE: --- VARY OFF SET RDEVICE TYPE . VARY ON --- John Franciscovich z/VM Development
VM TCP/IP console logging
Hey guys, We primarily use our VM TCP/IP for telnet. I recently, with help from the VM list, got our secure telnet up and in production. It has run with no problems until yesterday. Out secure telnet users all lost connection briefly. The VM operator log showed : 08/06/09 17:00:02 : 17:00:02 USER DSC LOGOFF AS SSLSERV USERS = 63FORCED BY TCPIP 08/06/09 17:00:12 : 17:00:12 AUTO LOGON *** SSLSERV USERS = 64BY TCPIP It is obvious that TCPIP cycled our SSLSERV Linux machine. What I am looking for is a TCPIP log that might show why it cycled SSLSERV. I am having trouble finding this log. I have the PROFILE TCPIP with a: INFORM OPERATOR TCPMAINT TIMJ MSINGLEY ENDINFORM But received no messages on these users. Should I have a : CONSOLE 009 3215 T OPERATOR console statement for TCPIP in our USER DIRECT? Can someone point me in the right direction? Thanks, Tim Tim Joyce Sr. Systems Programmer / Project Leader Alex Lee, Inc. Email : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Phone: (828) 725-4448 Fax: (828) 725-4800
Re: Defining Devices
Thanks, John. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of John Franciscovich Sent: Wednesday, June 11, 2008 11:32 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Defining Devices How do I change a device that partially emulates a 3480 from supported to unsupported without an ipl? I presume that the command SET RDEVICE TYPE UNSUP DEVCLASS TAPE would be needed. Would this need to be preceded by the command SET RDEVICE CLEAR? Would having the device OFFLINE before entering the command(s) be sufficient?=20 You shouldn't need SET RDEVICE CLEAR, but the device must be varied offline before you issue SET RDEVICE: --- VARY OFF SET RDEVICE TYPE . VARY ON --- John Franciscovich z/VM Development
Re: VM TCP/IP console logging
From a privileged id, i.e. MAINT, enter 'CP Q P ALL TCPIP' and you should get something like this: q p all tcpip ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE TCPIP0151 A CON 0174 001 NONE OPEN- 0009 Ready; T=0.01/0.01 15:42:29 This shows that TCPIP has an OPEN console file. Depending on when the console gets closed, and it may not have been closed since SSLSERV got recycled, you can enter 'NETSTAT CP CL CONS /your_own_id/' and you will get the TCPIP console log in your rdr. By default, the TCPIP and TCPIP related consoles get spooled to the userid TCPMAINT. You might find what you want there if the console has already been closed. Jim Tim Joyce wrote: This is a multi-part message in MIME format. --_=_NextPart_001_01C8CBF8.2FB43540 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hey guys, =20 We primarily use our VM TCP/IP for telnet. I recently, with help from the VM list, got our secure telnet up and in production. It has run with no problems until yesterday. Out secure telnet users all lost connection briefly. The VM operator log showed : =20 08/06/09 17:00:02 : 17:00:02 USER DSC LOGOFF AS SSLSERV USERS =3D 63FORCED BY TCPIP=20 08/06/09 17:00:12 : 17:00:12 AUTO LOGON *** SSLSERV USERS =3D 64BY TCPIP =20 =20 It is obvious that TCPIP cycled our SSLSERV Linux machine. What I am looking for is a TCPIP log that might show why it cycled SSLSERV. I am having trouble finding this log. I have the PROFILE TCPIP with a: =20 INFORM =20 OPERATOR TCPMAINT TIMJ MSINGLEY ENDINFORM =20 =20 But received no messages on these users. Should I have a : =20 CONSOLE 009 3215 T OPERATOR =20 console statement for TCPIP in our USER DIRECT? Can someone point me in the right direction? =20 Thanks, Tim Tim Joyce Sr. Systems Programmer / Project Leader=20 Alex Lee, Inc.=20 Email : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] =20 Phone: (828) 725-4448 =20 Fax: (828) 725-4800 =20 --_=_NextPart_001_01C8CBF8.2FB43540 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=3DContent-Type content=3Dtext/html; = charset=3Dus-ascii META content=3DMSHTML 6.00.2800.1609 name=3DGENERATOR/HEAD BODY DIVSPAN class=3D893210119-11062008FONT face=3DArialHey=20 guys,/FONT/SPAN/DIV DIVSPAN class=3D893210119-11062008FONT = face=3DArial/FONT/SPANnbsp;/DIV DIVSPAN class=3D893210119-11062008FONT face=3DArialWe primarily = use our VM=20 TCP/IP for telnet. I recently, with help from the VM list, got our = secure telnet=20 up and in production. It has run with no problems until yesterday. Out = secure=20 telnet users all lost connection briefly. The VM operator log showed=20 :/FONT/SPAN/DIV DIVSPAN class=3D893210119-11062008FONT = face=3DArial/FONT/SPANnbsp;/DIV DIVSPAN class=3D893210119-11062008FONT face=3DArialFONT=20 face=3DCourier New08/06/09=20 17:00:02nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp= ;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;=20 :nbsp; 17:00:02 USER DSCnbsp;nbsp; LOGOFF ASnbsp; SSLSERVnbsp; = USERS =3D=20 63nbsp;nbsp;nbsp; FORCED BY TCPIPnbsp;BR08/06/09=20 17:00:12nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp= ;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;=20 :nbsp; 17:00:12 AUTO LOGONnbsp; = ***nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;=20 SSLSERVnbsp; USERS =3D 64nbsp;nbsp;nbsp; BY=20 TCPIP/FONTnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; = /FONT/SPAN/DIV DIVFONT face=3DArial/FONTnbsp;/DIV DIVSPAN class=3D893210119-11062008FONT face=3DArialIt is obvious = that TCPIP=20 cycled our SSLSERV Linux machine. What I am looking for is a TCPIP log = that=20 might show why it cycled SSLSERV. I am having trouble finding this log. = I have=20 the PROFILE TCPIP with a:/FONT/SPAN/DIV DIVSPAN class=3D893210119-11062008FONT = face=3DArial/FONT/SPANnbsp;/DIV DIVSPAN class=3D893210119-11062008FONT face=3DArialFONT=20 face=3DCourier = NewINFORMnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;n= bsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nb= sp;nbsp;nbsp;nbsp;=20 BRnbsp; OPERATOR TCPMAINT TIMJ=20 MSINGLEYBRENDINFORMnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/FONTnbsp;nb= sp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbs= p;nbsp;nbsp;nbsp;=20 /FONT/SPAN/DIV DIVSPAN class=3D893210119-11062008FONT = face=3DArial/FONT/SPANnbsp;/DIV DIVSPAN class=3D893210119-11062008FONT face=3DArialBut received no = messages on=20 these users. Should I have a :/FONT/SPAN/DIV DIVSPAN class=3D893210119-11062008FONT = face=3DArial/FONT/SPANnbsp;/DIV DIVSPAN class=3D893210119-11062008FONT face=3DCourier = NewSTRONGCONSOLE 009=20 3215 T OPERATOR/STRONG/FONT/SPAN/DIV DIVSPAN class=3D893210119-11062008FONT =
Re: VM TCP/IP console logging
Thanks Jim. This got me what I needed: 16:59:59 DTCAPI001I IucvCheckRc: IUCV retcc 1 iprcode 24 on path 11 function 6 16:59:59 DTCAPI002IUserid SSLSERV TheSockNumber 6 16:59:59 DTCNOT009I *** Wrapup finds empty Notices queue *** 17:00:02 DTCIPI030W StartANewLife: Victim SSLSERV, reason Restarting you because KillClient called for reason: Fatal inter-VM communication error HCPLGA054E Already logged on disconnected USER DSC LOGOFF AS SSLSERV USERS = 63FORCED BY TCPIP 17:00:12 DTCIPI030W StartANewLife: Victim SSLSERV, reason Restarting you because TRYautologging scheduled AUTO LOGON *** SSLSERV USERS = 64 Now I've got to figure out what this means! Thanks again, Tim -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Wednesday, June 11, 2008 3:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM TCP/IP console logging From a privileged id, i.e. MAINT, enter 'CP Q P ALL TCPIP' and you should get something like this: q p all tcpip ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE TCPIP0151 A CON 0174 001 NONE OPEN- 0009 Ready; T=0.01/0.01 15:42:29 This shows that TCPIP has an OPEN console file. Depending on when the console gets closed, and it may not have been closed since SSLSERV got recycled, you can enter 'NETSTAT CP CL CONS /your_own_id/' and you will get the TCPIP console log in your rdr. By default, the TCPIP and TCPIP related consoles get spooled to the userid TCPMAINT. You might find what you want there if the console has already been closed. Jim Tim Joyce wrote: This is a multi-part message in MIME format. --_=_NextPart_001_01C8CBF8.2FB43540 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hey guys, =20 We primarily use our VM TCP/IP for telnet. I recently, with help from the VM list, got our secure telnet up and in production. It has run with no problems until yesterday. Out secure telnet users all lost connection briefly. The VM operator log showed : =20 08/06/09 17:00:02 : 17:00:02 USER DSC LOGOFF AS SSLSERV USERS =3D 63FORCED BY TCPIP=20 08/06/09 17:00:12 : 17:00:12 AUTO LOGON *** SSLSERV USERS =3D 64BY TCPIP =20 =20 It is obvious that TCPIP cycled our SSLSERV Linux machine. What I am looking for is a TCPIP log that might show why it cycled SSLSERV. I am having trouble finding this log. I have the PROFILE TCPIP with a: =20 INFORM =20 OPERATOR TCPMAINT TIMJ MSINGLEY ENDINFORM =20 =20 But received no messages on these users. Should I have a : =20 CONSOLE 009 3215 T OPERATOR =20 console statement for TCPIP in our USER DIRECT? Can someone point me in the right direction? =20 Thanks, Tim Tim Joyce Sr. Systems Programmer / Project Leader=20 Alex Lee, Inc.=20 Email : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] =20 Phone: (828) 725-4448 =20 Fax: (828) 725-4800 =20 --_=_NextPart_001_01C8CBF8.2FB43540 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=3DContent-Type content=3Dtext/html; = charset=3Dus-ascii META content=3DMSHTML 6.00.2800.1609 name=3DGENERATOR/HEAD BODY DIVSPAN class=3D893210119-11062008FONT face=3DArialHey=20 guys,/FONT/SPAN/DIV DIVSPAN class=3D893210119-11062008FONT = face=3DArial/FONT/SPANnbsp;/DIV DIVSPAN class=3D893210119-11062008FONT face=3DArialWe primarily = use our VM=20 TCP/IP for telnet. I recently, with help from the VM list, got our = secure telnet=20 up and in production. It has run with no problems until yesterday. Out = secure=20 telnet users all lost connection briefly. The VM operator log showed=20 :/FONT/SPAN/DIV DIVSPAN class=3D893210119-11062008FONT = face=3DArial/FONT/SPANnbsp;/DIV DIVSPAN class=3D893210119-11062008FONT face=3DArialFONT=20 face=3DCourier New08/06/09=20 17:00:02nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;n bsp= ;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;=20 :nbsp; 17:00:02 USER DSCnbsp;nbsp; LOGOFF ASnbsp; SSLSERVnbsp; = USERS =3D=20 63nbsp;nbsp;nbsp; FORCED BY TCPIPnbsp;BR08/06/09=20 17:00:12nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;n bsp= ;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;=20 :nbsp; 17:00:12 AUTO LOGONnbsp; = ***nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;=20 SSLSERVnbsp; USERS =3D 64nbsp;nbsp;nbsp; BY=20 TCPIP/FONTnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; = /FONT/SPAN/DIV DIVFONT face=3DArial/FONTnbsp;/DIV DIVSPAN class=3D893210119-11062008FONT face=3DArialIt is obvious = that TCPIP=20 cycled our SSLSERV Linux machine. What I am looking for is a
Re: Error handeling (Was: How to stop PIPE STARMON)
On Wed, Jun 11, 2008 at 12:29 PM, Berry van Sleeuwen [EMAIL PROTECTED] wrote: Are you sure this will work in all cases? The context of my suggestion was sipping pipelines in REXX. I do believe the streamstate does what makes sense, but I will check again when I get home. But more in general, there are more commands that will exit a returncode based on their function. WAKEUP for instance. Just a small test confirms I should have been more clear about the context. I do hope you would not be tempted to run wakeup from inside a REXX stage (and I don't use it at all now that we have pipes). PS The CMSPIP-L is probably a better place for this kind of threads. Rob
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Marcy, What is your network configuration like? Do you know what type of network hardware has been in place for the channel extension? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit FWIW, backing up about 360G of disk on the smaller system of our 2 traditional VM/CMS systems with HIDRO (uses 4 tapes, 2000 miles) takes a little less that 10 hours. The network is being beefed up. Then we will do full XRC mirroring instead (or too?). The restores are faster with HIDRO as well. Since we do monthly disaster tests, fast is good... (JR and Fran will tell you that too :) I figure too that using both vmbackup and hidro is some protection against sw bugs too that might corrupt both the primary and the secondary at the same time. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Llewellyn, Mark Sent: Thursday, June 05, 2008 2:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit That's another option I'll add to the list. The remote site is disaster-recovery only - it doesn't necessarily have to be pretty right off the bat. I'll have to figure out how it knows which tapes to call for where - it'll be a few months before we start real testing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We run VM:Backup to local tapes and HIDRO to remote tapes. HIDRO is much faster and doesn't chew the CPU the way VM:Backup does. But the users are used to getting their stuff out of the much prettier vmbackup interface. If you twin remotely and locally, how does the restores work? Do you have to code to just use the local drives for that? Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: Printing a TRSOURCE/IPFORMAT Trace
Mark, that did the trick. Thanks. I'll follow up on the un-ordered display of selected packets. Mark Cibula [EMAIL PROTECTED] 6/11/2008 8:36 AM Hi Dick, The 'formatted' IPFORMAT data file (file type IPFDATA) is packed with the= PIPE PACK stage. If you process this file with the PIPE UNPACK stage, you= 'll have a flat file that contains all of the formatted packet data (after th= e packet 'summary') in a more legible form, that you can edit, print as needed... The Pipe below will create suh a flat file: pipe tracex ipfdata a | unpack | tracex prtdata a The various formatted packets are prefixed using a Pn marker string. Regarding the (un?) ordered display of selected packets , this could be d= ue to a bug in the code. If you'd like to pursue that further, just open a = PMR with the support center... Regards, Mark Cibula, IBM z/VM Systems Management The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you.
Re: VM TCP/IP console logging
On Wednesday, 06/11/2008 at 04:10 EDT, Tim Joyce [EMAIL PROTECTED] wrote: Thanks Jim. This got me what I needed: 16:59:59 DTCAPI001I IucvCheckRc: IUCV retcc 1 iprcode 24 on path 11 function 6 16:59:59 DTCAPI002IUserid SSLSERV TheSockNumber 6 16:59:59 DTCNOT009I *** Wrapup finds empty Notices queue *** 17:00:02 DTCIPI030W StartANewLife: Victim SSLSERV, reason Restarting you because KillClient called for reason: Fatal inter-VM communication error HCPLGA054E Already logged on disconnected USER DSC LOGOFF AS SSLSERV USERS = 63FORCED BY TCPIP 17:00:12 DTCIPI030W StartANewLife: Victim SSLSERV, reason Restarting you because TRYautologging scheduled AUTO LOGON *** SSLSERV USERS = 64 Now I've got to figure out what this means! It means Look at SSLSERV's console log and see what's happening. :-) If you haven't already done so, you need to call the Support Center (VM TCP/IP) and ask for an updated version of SSL. We have a fix-test version for 5.2 and 5.3. Alan Altmark z/VM Development IBM Endicott
Filepool Names
Is it possible to create filepool X: on our first level system by FILEPOOL UNLOAD of one storage group of our main filepool (say one named M:), copy the definition of the X: machine to the 2nd level system and change the filepool name from X: to M:? This M: nee X: filepool would be isolated on a set of disks and would never be brought up 1st level again following the UNLOAD. I can guarantee that because I will delete the userid from the first level system following the unload. Regards, Richard Schuh
Re: Filepool Names
I did that to test my SFS backup/restore procedures. I made M and X be equal to the userids of the virtual machines they ran in so that I was sure of which filepool I was working with. First time was from first level to second level, but because it worked so well, but slowly, I moved X to first level and everything still works just fine. /Tom Kern Schuh, Richard wrote: Is it possible to create filepool X: on our first level system by FILEPOOL UNLOAD of one storage group of our main filepool (say one named M:), copy the definition of the X: machine to the 2nd level system and change the filepool name from X: to M:? This M: nee X: filepool would be isolated on a set of disks and would never be brought up 1st level again following the UNLOAD. I can guarantee that because I will delete the userid from the first level system following the unload. Regards, Richard Schuh
