Dirmaint question
Hi Folks. Yesterday, one of our administators issued a DIRM FOR ONGWW02 PURGE to delete a z/VM user. Checking to see if this was done, he issued DIRM FOR ONGWW02 REV and got the following back: DVHREQ3205E The directory entry for ONGWW02 is scheduled to be purged. I did a DIRM STATUS to see if there were any pending workunits and did not see any. This AM, I checked and still seeing the purge is still scheduled. The only DASD in the directory entry right now (from a DIRM USER) is LINKS to other minidisks. I have recycled both DIRMAINT and DATAMOVE but no change. What's going on? What's it waiting for? How do I fix this? Thanks!
Re: uploading C code to VM
You know Tony, you could use VSE Connectors to perform the submit (and wrap the JCL around the job) and retrieve the output to your Linux Boxnever see a z/VSE. Frank M. Ramaekers Jr. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Tony Thigpen Sent: Thursday, May 19, 2011 5:23 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: uploading C code to VM I figured I would post my current resolution for this thead, for those that care. Several mentioned that C under VM would handle longer record lengths. I found that under VSE, there also existed one option for longer record lengths. While SYSIN and LIBR are limited to 80, VSAM input was not limited and could handle lines up to about 32k long. After some testing and also considering the fact that there are better editors on my linux desktop for C code, I decided to just keep the source on my pc and just upload it to VSE each time I needed to compile it. Below is the current version of my jcl that performs an FTP from my laptop into a VSAM ESDS file, then compiles it. Of course I plan on trying to clean it up a lot. (This was just a proof-of-concept test.) // JOB COMPC // EXEC IDCAMS,SIZE=IDCAMS DELETE (COMPIPT) CL PURGE - CAT(OEM.USER.CATALOG) DEFINE CLUSTER - (NAME(COMPIPT) - NONINDEXED - RECSZ(1 32748) - CYL(1 1) - VOLUME(TEI002) - FREESPACE(0 0)) - DATA(NAME(COMPIPT.DATA)) - CATALOG(OEM.USER.CATALOG) /* // DLBL COMPIPT,'COMPIPT',,VSAM,CAT=OEMCAT // LIBDEF *,SEARCH=(DEVLIB.LOCAL, /INCLUDE BSITT LIBDEF STGLIB.LOCAL) // EXEC BSTTFTPC,SIZE=BSTTFTPC,OS390 TASKS=ANY ID 41 OPEN 192.168.1.100 USER [[[ PASS [[[ CWD mydata/Sockets LF ON * NOW HANDLE NULL LINES PADCHAR 64 * HANDLE [ TRANSLATE ASCII 091 173 * HANDLE ] TRANSLATE ASCII 093 189 * HANDLE A TAB CHARACTER TRANSLATE ASCII 009 064 TYPE A OUTPUT ESDS COMPIPT RECSZ 4089 RETR selectserver.c QUIT /* /. PRINT // GOTO COMP // DLBL COMPIPT,'COMPIPT',,VSAM,CAT=OEMCAT // EXEC IDCAMS,SIZE=AUTO PARM GRAPHICS(CHAIN(SN)) PRINT INFILE(COMPIPT) /* /. COMP // DLBL COMPIPT,'COMPIPT',,VSAM,CAT=OEMCAT // DLBL SYSMSGS,'CVSE.COMP.MSGS',0,VSAM,RECSIZE=3000,RECORDS=35, X CAT=VSESPUC // LIBDEF *,SEARCH=(PRD2.SCEEBASE,PRD2.DBASE) // SETPARM CATALOG=1 // IF CATALOG = 1 THEN // GOTO CAT // OPTION ERRS,SXREF,SYM,LIST,NODECK // GOTO ENDCAT /. CAT // LIBDEF PHASE,CATALOG=DEVLIB.LOCAL // OPTION ERRS,SXREF,SYM,NODECK,CATAL PHASE TONYTEST,* /. ENDCAT // EXEC EDCCOMP,SIZE=EDCCOMP,PARM='NATLANG(ENU)/LONGNAME,RENT,OFFSET,- SS,SHOWINC,INFILE(DD:COMPIPT)' /* // IF CATALOG NE 1 OR $MRC GT 4 THEN // GOTO NOLNK // EXEC EDCPRLK,SIZE=EDCPRLK,PARM='NATLANG(ENU)/UPCASE' /* // EXEC LNKEDT,SIZE=256K /. NOLNK / Tony Thigpen _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
DASD HA R0 ?
Can anyone point me to a doc that has the format of ECKD Home Address (HA) and Record 0 (R0) records? Thanks
Re: Dirmaint question
Karl. Is it possible that a user may still have an active link to the ONGWW02 minidisk? Hans From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Karl Kingston Sent: May-20-11 7:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Dirmaint question Hi Folks. Yesterday, one of our administators issued a DIRM FOR ONGWW02 PURGE to delete a z/VM user. Checking to see if this was done, he issued DIRM FOR ONGWW02 REV and got the following back: DVHREQ3205E The directory entry for ONGWW02 is scheduled to be purged. I did a DIRM STATUS to see if there were any pending workunits and did not see any. This AM, I checked and still seeing the purge is still scheduled. The only DASD in the directory entry right now (from a DIRM USER) is LINKS to other minidisks. I have recycled both DIRMAINT and DATAMOVE but no change. What's going on? What's it waiting for? How do I fix this? Thanks!
Re: DASD HA R0 ?
On Friday, 05/20/2011 at 09:00 EDT, Tom Huegel tehue...@gmail.com wrote: Can anyone point me to a doc that has the format of ECKD Home Address (HA) and Record 0 (R0) records? It's odd that the most recent programming reference for ECKD DASD (IBM ESS S/390 Command Reference, SC26-7298) does not describe the format of the HA except to say that it is 5 bytes. Dragging out an old 3880 book, READ HOME ADDRESS transfers the flag, cylinder, and head bytes of the home address area. I'm assuming that's of the form FCCHH. I only see a description of flag byte bits 6-7='10': Next track defective. In that same 3880 book, READ SPECIAL HOME ADDRESS transfers the skip control bytes, segment number, physical address bytes, flag, and identifier bytes (CCHH) of the home address area with no further description. I'm guessing that detailed HA content is part of the proprietary disk architecture, but you'd have to raise a problem to your storage vendor to find out. R0 doesn't have any special format except that it is 8 bytes with KL=0. The most r Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Dirmaint question
Greetings Karl, There was an APAR on DirMaint FL540 and FL610 (VM64724 - PURGE CLEAN ON USERID WITH VDISK DOES NOT COMPLETE). PTFs: Release 540 : UV61094 Release 610 : UV61095 When a user entry contains VDISK or TDISK minidisks, DirMaint would not finish PURGE processing correctly. When a user is stuck in this state--purge is still pending but there are no left over workunits associated with the id--you will need to delete the user's entry in the PURGES PENDING file on the DIRMAINT 155 disk. Once t he record is deleted in the PURGES PENDING file, you can reissue the DIRM FO R userid PURGE command and the PURGE should then work correctly. If the user did not contain VDISK or TDISK minidisks, then this is a new problem for which a PMR should be opened. Regards, Mike Wilkins z/VM Development
Re: Coloring the STATUS area
Hi, So far it looks like the terminal emulator indeed is the bad guy in this case - I'm still waiting for support. Beside that it works well for virtual machines if I place appropriate statements to the directory. However, this does not work for the LOGON screen as this one is not yet assigned to any virtual machine. I know already that the look of the LOGON screen can be widely configured and even with different colors for any field but the status area which obviously gets its color from the system's default value. Now, can the latter be defined somewhere as well? If not, in which module / control block is it hard coded? Thank you, Wolfgang -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Buettner, Wolfgang Sent: Friday, May 13, 2011 4:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Coloring the STATUS area I'd like to give the STATUS area different colors on different z/VM systems. The command SCREEN STATAREA color in the CP directory seems to be a solution. However, the desired result appears only after hitting the CLEAR key while after hitting ENTER the default color blue returns - wherever this default comes from. Is this a bug or a feature? Are there other possibilities to get that done? And what is before the virtual machine gets control over the terminal? Thank you, Wolfgang Software AG - Group Executive Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Arnd Zinnhardt, Mark Edwards, David Broadbent, Dr. Hans Kraus, Dr. Wolfram Jost, Kamyar Niroumand, Ivo Totev Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany, - Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/ Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David Broadbent, Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/ Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com/
Re: Dirmaint question
Karl, Did you check all the variations of DIRM STATUS? See DIRM HELP STATUS Looks like a Workunit not assigned, due a Mdisk or Userid locked. Regards, __ Clovis From: Karl Kingston karlkings...@ongov.net To: IBMVM@listserv.uark.edu Date: 20/05/2011 08:47 Subject: Dirmaint question Sent by: The IBM z/VM Operating System IBMVM@listserv.uark.edu Hi Folks. Yesterday, one of our administators issued a DIRM FOR ONGWW02 PURGE to delete a z/VM user. Checking to see if this was done, he issued DIRM FOR ONGWW02 REV and got the following back: DVHREQ3205E The directory entry for ONGWW02 is scheduled to be purged. I did a DIRM STATUS to see if there were any pending workunits and did not see any. This AM, I checked and still seeing the purge is still scheduled. The only DASD in the directory entry right now (from a DIRM USER) is LINKS to other minidisks. I have recycled both DIRMAINT and DATAMOVE but no change. What's going on? What's it waiting for? How do I fix this? Thanks!
Antwort: Re: Coloring the STATUS area
Herr Buettner, eine Lösung wäre eine PC3270 Profile für jede Maschine, ich setze z.B. meine Test Maschinen in Blau. Hier meine zVMTest: Mit freundlichen Grüßen Regards, William Kim Mongan _ Basler Versicherungs-Aktiengesellschaft Abteilung INF-SP Basler Straße 4, D-61281 Bad Homburg Postfach 11 45 Tel. +49 (0) 61 72 / 13 - 253 Fax +49 (0) 61 72 / 131 - 253 mailto:william.mon...@basler.de Buettner, Wolfgang Wolfgang.Buettne An r...@softwareag.com IBMVM@LISTSERV.UARK.EDU Gesendet von: The Kopie IBM z/VM Operating SystemThema IBMVM@LISTSERV.U Re: Coloring the STATUS area ARK.EDU 20.05.2011 16:51 Bitte antworten an The IBM z/VM Operating System IBMVM@LISTSERV.U ARK.EDU Hi, So far it looks like the terminal emulator indeed is the bad guy in this case - I'm still waiting for support. Beside that it works well for virtual machines if I place appropriate statements to the directory. However, this does not work for the LOGON screen as this one is not yet assigned to any virtual machine. I know already that the look of the LOGON screen can be widely configured and even with different colors for any field but the status area which obviously gets its color from the system's default value. Now, can the latter be defined somewhere as well? If not, in which module / control block is it hard coded? Thank you, Wolfgang -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Buettner, Wolfgang Sent: Friday, May 13, 2011 4:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Coloring the STATUS area I'd like to give the STATUS area different colors on different z/VM systems. The command SCREEN STATAREA color in the CP directory seems to be a solution. However, the desired result appears only after hitting the CLEAR key while after hitting ENTER the default color blue returns - wherever this default comes from. Is this a bug or a feature? Are there other possibilities to get that done? And what is before the virtual machine gets control over the terminal? Thank you, Wolfgang Software AG - Group Executive Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Arnd Zinnhardt, Mark Edwards, David Broadbent, Dr. Hans Kraus, Dr. Wolfram Jost, Kamyar Niroumand, Ivo Totev Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany, - Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/ Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David Broadbent, Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/ Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com/ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: DASD HA R0 ?
I think I remember R0 being referred to as the Track Capacity record. It was not a constant, but held the remaining capacity after the last formatting write. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Friday, May 20, 2011 7:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DASD HA R0 ? On Friday, 05/20/2011 at 09:00 EDT, Tom Huegel tehue...@gmail.com wrote: Can anyone point me to a doc that has the format of ECKD Home Address (HA) and Record 0 (R0) records? It's odd that the most recent programming reference for ECKD DASD (IBM ESS S/390 Command Reference, SC26-7298) does not describe the format of the HA except to say that it is 5 bytes. Dragging out an old 3880 book, READ HOME ADDRESS transfers the flag, cylinder, and head bytes of the home address area. I'm assuming that's of the form FCCHH. I only see a description of flag byte bits 6-7='10': Next track defective. In that same 3880 book, READ SPECIAL HOME ADDRESS transfers the skip control bytes, segment number, physical address bytes, flag, and identifier bytes (CCHH) of the home address area with no further description. I'm guessing that detailed HA content is part of the proprietary disk architecture, but you'd have to raise a problem to your storage vendor to find out. R0 doesn't have any special format except that it is 8 bytes with KL=0. The most r Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: DASD HA R0 ?
Thanks Alan that actually is a great help. I wish I could find what the format of content of R0's data area is. On Fri, May 20, 2011 at 7:04 AM, Alan Altmark alan_altm...@us.ibm.comwrote: On Friday, 05/20/2011 at 09:00 EDT, Tom Huegel tehue...@gmail.com wrote: Can anyone point me to a doc that has the format of ECKD Home Address (HA) and Record 0 (R0) records? It's odd that the most recent programming reference for ECKD DASD (IBM ESS S/390 Command Reference, SC26-7298) does not describe the format of the HA except to say that it is 5 bytes. Dragging out an old 3880 book, READ HOME ADDRESS transfers the flag, cylinder, and head bytes of the home address area. I'm assuming that's of the form FCCHH. I only see a description of flag byte bits 6-7='10': Next track defective. In that same 3880 book, READ SPECIAL HOME ADDRESS transfers the skip control bytes, segment number, physical address bytes, flag, and identifier bytes (CCHH) of the home address area with no further description. I'm guessing that detailed HA content is part of the proprietary disk architecture, but you'd have to raise a problem to your storage vendor to find out. R0 doesn't have any special format except that it is 8 bytes with KL=0. The most r Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: DASD HA R0 ?
Richard, That is sort of what I remember too, maybe I'll do some searches on 'Track Capacity Record'. Thanks On Fri, May 20, 2011 at 8:52 AM, Schuh, Richard rsc...@visa.com wrote: I think I remember R0 being referred to as the Track Capacity record. It was not a constant, but held the remaining capacity after the last formatting write. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Friday, May 20, 2011 7:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DASD HA R0 ? On Friday, 05/20/2011 at 09:00 EDT, Tom Huegel tehue...@gmail.com wrote: Can anyone point me to a doc that has the format of ECKD Home Address (HA) and Record 0 (R0) records? It's odd that the most recent programming reference for ECKD DASD (IBM ESS S/390 Command Reference, SC26-7298) does not describe the format of the HA except to say that it is 5 bytes. Dragging out an old 3880 book, READ HOME ADDRESS transfers the flag, cylinder, and head bytes of the home address area. I'm assuming that's of the form FCCHH. I only see a description of flag byte bits 6-7='10': Next track defective. In that same 3880 book, READ SPECIAL HOME ADDRESS transfers the skip control bytes, segment number, physical address bytes, flag, and identifier bytes (CCHH) of the home address area with no further description. I'm guessing that detailed HA content is part of the proprietary disk architecture, but you'd have to raise a problem to your storage vendor to find out. R0 doesn't have any special format except that it is 8 bytes with KL=0. The most r Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Coloring the STATUS area
On Friday, 05/20/2011 at 10:52 EDT, Buettner, Wolfgang wolfgang.buett...@softwareag.com wrote: However, this does not work for the LOGON screen as this one is not yet assigned to any virtual machine. I know already that the look of the LOGON screen can be widely configured and even with different colors for any field but the status area which obviously gets its color from the system's default value. Now, can the latter be defined somewhere as well? If not, in which module / control block is it hard coded? The STATUS area of the logo is not configurable. It is built dynamically in HCPBOY at run time. Look at the use of ORDPRLO (protected,low-intensity) in the SKLSTAT structure. You will need the High Level Assembler to reassemble the module. Of course, changing that does not help if you press ENTER before you log on. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: DASD HA R0 ?
On Friday, 05/20/2011 at 11:55 EDT, Tom Huegel tehue...@gmail.com wrote: Thanks Alan that actually is a great help. I wish I could find what the format of content of R0's data area is. There is no architected format. It's for the OS to use as it wishes. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: DASD HA R0 ?
On: Fri, May 20, 2011 at 08:54:18AM -0700,Tom Huegel Wrote: } Thanks Alan that actually is a great help. I wish I could find what the } format of content of R0's data area is. The last time I needed that format, I am fairly sure I found it in the control blocks/data area manual. However that was a Lng time ago. I have an old VM collection on CD. I will take a look. -- Rich Greenberg Sarasota, FL, USA richgr atsign panix.com + 1 941 378 2097 Eastern time. N6LRT I speak for myself my dogs only.VM'er since CP-67 Canines: Val, Red, Shasta, Zero Casey (At the bridge)Owner:Chinook-L Canines: Red Cinnar (Siberians) Retired at the beach Asst Owner:Sibernet-L
Re: DASD HA R0 ?
On Friday, 05/20/2011 at 11:55 EDT, Schuh, Richard rsc...@visa.com wrote: I think I remember R0 being referred to as the Track Capacity record. It was not a constant, but held the remaining capacity after the last formatting write. It is possible that some OSes write things to R0, but CMS and CP don't. CMS FORMAT and DSF write R0 and HA with zeros. Use DDR PRINT 0 0 0 to see them. Each time you WRITE R0, you erase the track. Track capacity is determined by using formulae described in the book with data from the READ DEVICE CHARACTERISTICS command. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
VM TCP/IP I/O error?
Greetings, This morning we received the following message on the console of a TCPIP machine: DTCPKT089I Device LCS3: LAN task net type 1 adapter number 0 was interrupted; restarting device I was told by IBM that this is a hardware issue presumably on the OSA card. How can I find out the cause of this problem? No messages seems to appear anywhere else. Thanks, Michael Horlick CGI Montreal
Re: VM TCP/IP I/O error?
Call your IBM CE! Marcy From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Horlick, Michael Sent: Friday, May 20, 2011 11:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] VM TCP/IP I/O error? Greetings, This morning we received the following message on the console of a TCPIP machine: DTCPKT089I Device LCS3: LAN task net type 1 adapter number 0 was interrupted; restarting device I was told by IBM that this is a hardware issue presumably on the OSA card. How can I find out the cause of this problem? No messages seems to appear anywhere else. Thanks, Michael Horlick CGI Montreal
Re: VM TCP/IP I/O error?
Hello, Thanks. I think the last time it was looked at they didn't find anything (but I don't know all the details) . I assume something is recorded somewhere, right? Michael Horlick CGI Montreal From: The IBM z/VM Operating System on behalf of Marcy Cortes Sent: Fri 20/05/2011 2:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM TCP/IP I/O error? Call your IBM CE! Marcy From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Horlick, Michael Sent: Friday, May 20, 2011 11:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] VM TCP/IP I/O error? Greetings, This morning we received the following message on the console of a TCPIP machine: DTCPKT089I Device LCS3: LAN task net type 1 adapter number 0 was interrupted; restarting device I was told by IBM that this is a hardware issue presumably on the OSA card. How can I find out the cause of this problem? No messages seems to appear anywhere else. Thanks, Michael Horlick CGI Montreal
Re: VM TCP/IP I/O error?
Do you process your EREP data? It should be there. On Fri, May 20, 2011 at 2:30 PM, Horlick, Michael michael.horl...@cgi.comwrote: Hello, Thanks. I think the last time it was looked at they didn't find anything (but I don't know all the details) . I assume something is recorded somewhere, right? Michael Horlick CGI Montreal From: The IBM z/VM Operating System on behalf of Marcy Cortes Sent: Fri 20/05/2011 2:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM TCP/IP I/O error? Call your IBM CE! Marcy From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Horlick, Michael Sent: Friday, May 20, 2011 11:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] VM TCP/IP I/O error? Greetings, This morning we received the following message on the console of a TCPIP machine: DTCPKT089I Device LCS3: LAN task net type 1 adapter number 0 was interrupted; restarting device I was told by IBM that this is a hardware issue presumably on the OSA card. How can I find out the cause of this problem? No messages seems to appear anywhere else. Thanks, Michael Horlick CGI Montreal -- Mark D Pace Senior Systems Engineer Mainline Information Systems
Re: VM TCP/IP I/O error?
Not really; an OSA is a pretty dumb animal and it does not record any errors. But there are some diagnostics that can be run. David Wakser -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Friday, May 20, 2011 2:30 PM To: IBMVM@listserv.uark.edu Subject: Re: VM TCP/IP I/O error? Hello, Thanks. I think the last time it was looked at they didn't find anything (but I don't know all the details) . I assume something is recorded somewhere, right? Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: DASD HA R0 ?
Must have been a thing from OS/360, then, probably from a time before there was Sense id and RDC. Writing the capacity of the track in R0 might have been helpful in those days. The fact that the Write R0 CCW erases the entire track insures that the part about updating it is incorrect. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Friday, May 20, 2011 10:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DASD HA R0 ? On Friday, 05/20/2011 at 11:55 EDT, Schuh, Richard rsc...@visa.com wrote: I think I remember R0 being referred to as the Track Capacity record. It was not a constant, but held the remaining capacity after the last formatting write. It is possible that some OSes write things to R0, but CMS and CP don't. CMS FORMAT and DSF write R0 and HA with zeros. Use DDR PRINT 0 0 0 to see them. Each time you WRITE R0, you erase the track. Track capacity is determined by using formulae described in the book with data from the READ DEVICE CHARACTERISTICS command. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: VM TCP/IP I/O error?
I just did and unless I'm not specifying the right parameters to the EREP program I don't see any errors on my OSA address. SYSEXN = YES, SYSUM=YES, EVENT=YES specified on seperate runs. Looking at the raw data itself I see nothing like my OSA address. Michael Horlick CGI Montreal From: The IBM z/VM Operating System on behalf of Mark Pace Sent: Fri 20/05/2011 2:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM TCP/IP I/O error? Do you process your EREP data? It should be there. On Fri, May 20, 2011 at 2:30 PM, Horlick, Michael michael.horl...@cgi.com wrote: Hello, Thanks. I think the last time it was looked at they didn't find anything (but I don't know all the details) . I assume something is recorded somewhere, right? Michael Horlick CGI Montreal From: The IBM z/VM Operating System on behalf of Marcy Cortes Sent: Fri 20/05/2011 2:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM TCP/IP I/O error? Call your IBM CE! Marcy From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Horlick, Michael Sent: Friday, May 20, 2011 11:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] VM TCP/IP I/O error? Greetings, This morning we received the following message on the console of a TCPIP machine: DTCPKT089I Device LCS3: LAN task net type 1 adapter number 0 was interrupted; restarting device I was told by IBM that this is a hardware issue presumably on the OSA card. How can I find out the cause of this problem? No messages seems to appear anywhere else. Thanks, Michael Horlick CGI Montreal -- Mark D Pace Senior Systems Engineer Mainline Information Systems
Re: DASD HA R0 ?
If you're going back that far, ISTR that R0, if writeable at all, was used on an otherwise bad track to point to its alternate. -- Mike Harding z/VM System Support mhard...@us.ibm.com mike.b.hard...@kp.org mikehard...@mindless.com (925) 926-3179 (w) (925) 323-2070 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 05/20/2011 11:56:14 AM: From: Schuh, Richard rsc...@visa.com To: IBMVM@LISTSERV.UARK.EDU Date: 05/20/2011 11:56 AM Subject: Re: DASD HA R0 ? Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Must have been a thing from OS/360, then, probably from a time before there was Sense id and RDC. Writing the capacity of the track in R0 might have been helpful in those days. The fact that the Write R0 CCW erases the entire track insures that the part about updating it is incorrect. Regards, Richard Schuh
Re: VM TCP/IP I/O error?
On Friday, 05/20/2011 at 02:02 EDT, Horlick, Michael michael.horl...@cgi.com wrote: This morning we received the following message on the console of a TCPIP machine: DTCPKT089I Device LCS3: LAN task net type 1 adapter number 0 was interrupted; restarting device I was told by IBM that this is a hardware issue presumably on the OSA card. How can I find out the cause of this problem? There is no problem, per se. That messages means that the OSA detected an unplugged cable or a dark switch port. Think of it as loss of carrier signal. You will see this when someone reboots the switch. You didn't say anything about what release of VM you are running. In early 2010, APAR PK92409 changed the behavior of the LCS device driver so that in addition to the message above, you also get a message telling you that the adapter will be restarted when an adapter-initiated START LAN is received. I.e., the carrier signal is heard. APPLICABLE COMPONENT LEVEL/SU: R530 PSY UK53847 UP10/01/28 P 1001 R540 PSY UK53848 UP10/01/28 P 1002 R610 PSY UK53849 UP10/01/28 P 1001 Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: VM TCP/IP I/O error?
Hello Michael Horlick, Did you look at the HMC to see if there are any messages? Or if the card has any flashing lights? Ed Martin Aultman Health Foundation 330-363-5050 Ext 35050 From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Horlick, Michael Sent: Friday, May 20, 2011 2:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM TCP/IP I/O error? Greetings, This morning we received the following message on the console of a TCPIP machine: DTCPKT089I Device LCS3: LAN task net type 1 adapter number 0 was interrupted; restarting device I was told by IBM that this is a hardware issue presumably on the OSA card. How can I find out the cause of this problem? No messages seems to appear anywhere else. Thanks, Michael Horlick CGI Montreal
Re: DASD HA R0 ?
I don't think that there is any doubt about it being writable, There was a CCW for it. Writing record 0 was all that was needed to clear a track when you initialized a track (not a security write). There was also Write Home Address which marked the start of a track. It was needed for new disks. The vendor did not initialize them way back then. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Michael Harding Sent: Friday, May 20, 2011 12:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DASD HA R0 ? If you're going back that far, ISTR that R0, if writeable at all, was used on an otherwise bad track to point to its alternate. -- Mike Harding z/VM System Support mhard...@us.ibm.com mike.b.hard...@kp.org mikehard...@mindless.com (925) 926-3179 (w) (925) 323-2070 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 05/20/2011 11:56:14 AM: From: Schuh, Richard rsc...@visa.com To: IBMVM@LISTSERV.UARK.EDU Date: 05/20/2011 11:56 AM Subject: Re: DASD HA R0 ? Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Must have been a thing from OS/360, then, probably from a time before there was Sense id and RDC. Writing the capacity of the track in R0 might have been helpful in those days. The fact that the Write R0 CCW erases the entire track insures that the part about updating it is incorrect. Regards, Richard Schuh
Re: Anyone use The Hessling Editor (THE), an Xedit/Kedit look-alike, for off-line VM code development or personal use?
On 5/19/2011 at 10:00 AM, Tony Thigpen t...@vse2pdf.com wrote: I use SUSE, not windows. Smart man, even if am biased. :) Mark Post
