|Planet MVS User Experiences OS/390 R6 upgrade experiences|
|Dave's OS/390 R6 upgrade experiences IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.|
The hardest part of an OS/390 upgrade is getting all of the program products upgraded to a compatible level.We spent the last few months upgrading to the latest greatest levels of our program products. We prefer to upgrade to newer releases of program products prior to an O/S upgrade to minimize the number of new/changed things.
|SYS1.PARMLIB.OS390R2.CSW||Overrides which are R2 specific and created by my installation (CSW).|
|SYS1.PARMLIB||Stuff that is common to all OS/390 releases|
|SYS1.PARMLIB.OS390R2.IBM||CTI (trace) and IPCS members from IBM. These are the members which are supplied by IBM, change from release to release and are not typically changed by the customer. This entire library is copied from SYS1.IBM.PARMLIB|
|Here is the entries in SYS1.IPLPARM(LOADxx) which
make this possible:|
* |<------------- Dataset name ------------->| Volume *---+----1----+----2----+----3----+----4----+----5----+----6----+---- PARMLIB SYS1.PARMLIB.OS390R2.CSW *MCAT* PARMLIB SYS1.PARMLIB *MCAT* PARMLIB SYS1.PARMLIB.OS390R2.IBM *MCAT*
|I agree with you if you initially HATE my PARMLIB dsnames but I want to goto ISPF 3.4 and get to all of my PARMLIBs easy!|
|SYS1.PROCLIB.OS390R2.CSW||Overrides which are R2 specific and created my my installation (CSW).|
|SYS1.PROCLIB||Stuff that is common to all OS/390 releases|
|SYS1.PROCLIB.OS390R2.IBM||These are the procs supplied by IBM which change from release to release. This entire library is copied from SYS1.IBM.PROCLIB.|
You should change two places to make this happen:
//MSTJCL10 JOB MSGLEVEL=(1,1),TIME=1440 // EXEC PGM=IEEMB860,DPRTY=(15,15) //STCINRDR DD SYSOUT=(A,INTRDR) //TSOINRDR DD SYSOUT=(A,INTRDR) //IEFPDSI DD DSN=SYS1.PROCLIB.OS390R2.CSW,DISP=SHR // DD DSN=SYS1.PROCLIB,DISP=SHR // DD DSN=SYS1.PROCLIB.OS390R2.IBM,DISP=SHR //IEFJOBS DD DSN=SYSL.SYS.STCJOBS.CSW1MVS,DISP=SHR //SYSUADS DD DSN=SYS1.UADS,DISP=SHR //SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR /*
//JES2 PROC ENTRY=HASJES20, // P='WARM,NOREQ', ... //************************************ //IEFPROC EXEC PGM=&ENTRY.,TIME=1440, // DPRTY=(15,15),PARM='&P' //HASPLIST DD DDNAME=IEFRDER //* //PROC00 DD DISP=SHR,DSN=SYS1.PROCLIB.OS390R2.CSW // DD DISP=SHR,DSN=SYS1.PROCLIB // DD DISP=SHR,DSN=SYS1.PROCLIB.OS390R2.IBM // DD DISP=SHR,DSN=CEE.SCEEPROC // DD DISP=SHR,DSN=user.proclibs here ...
FIXED MAX(120M) ECSA MAX(120M)[14 June 1999] - I just found out about this page: IBM eNetwork Communications Server for OS/390 IP Services Informational APARs
Join the IBMTCP_-L mailing list by by sending an email with "sub IBMTCP-L your name" in the body to email@example.com
We stumbled into work in the wee hours Saturday morning, 8 May 1999, and since then we have found these problems:
Clarification: Most of these errors were found in production because we lost two scheduled test times due to customer needs. We knew going in that we would be finding a few things to correct. We had one prior short test in the production environment.
Solution: USS messages other than MSG10 were removed.
Solution:Currently using the USS implementation ASIS without adding data passing.
Solution: Waited for next bounce of TCP/IP to clear problem. The operators had to manually clean the SPOOL of canceled TCPIP AUTOLOG tasks.
Solution: Set MAXPROCSYS to 2000
Solution: IPL to add a second TCP/IP task!!! How User-Friendly!
24 May 1999 -
Looking back I now see why I used INET:
The ServerPac comes with a
manual called "ServerPac: Installing Your Order". Mine said:
This is good advice AS LONG AS YOU ONLY NEED TO RUN ONE TCP/IP STACK.BPXPRMxx member should be updated to contain the following: FILESYSTYPE TYPE(INET) ENTRYPOINT(EZBPFINI) SUBFILESYSTYPE NAME(TCPIP) TYPE(INET) ENTRYPOINT(EZBPFINI) NETWORK DOMAINNAME(AF_INET) DOMAINNUMBER(2) MAXSOCKETS(10000) TYPE(INET)
TELNETPARMS INACTIVE 600 ENDTELNETPARMSThis caused TN3270 users to time out after 10 minutes of inactivity (Not good!). Trying to change this value dynamically via the operator command "VARY TCPIP,TCPIP,O,obey-file-name" did not change the value. (which you can check via "D TCPIP,TCPIP,T,PROF").
Solution: It works when you do it right!
Solution: I went back to using members in SYS1.TCPPARMS.
John M Krogulecki emailed me that:If you stick a free=close on them, you can edit them with the STC running.
Our proc, for instance, has://PROFILE DD DISP=SHR,DSN=TCPIP.&SYSNAME..TCPIP,FREE=CLOSE
Solution: Barry Dent sent me an email:APAR OW29618 explains the JES2 shutdown problem, you need to issueF BPXOINIT,SHUTDOWN=FORKINITto cancel any BPXAS address spaces.I'd also like to thank Peter Briedis and Matt Martin who also emailed me with this fix.
17 May 1999 - We did find that IBM went back to enforcing the rule that you can't do a IDCAMS DELETE/DEFINE/REPRO-OUTFILE of the same dataset in the same step. If the IDCAMS step is changed to two steps or the OUTDATASET() is used instead of OUTFILE(), then it works. A few production jobs had to be modified. There is an APAR on this (sorry I don't have the number at home) dated 1987 and last modified in 1998. My S.W.A.G. is that this got changed at DFSMS 1.4.
Solution: Unscheduled IPL
Solution: I made a post to the IBMTCP-L mailing list describing this problem and Joe.Kimberly posted back that Centura wrote them a fix for this problem. We then contacted Peoplesoft who then sent us a fix which has cleared up the problem.
Solution: 17 May 1999 - Applied fix from CA (sorry don't have PTF number)
Dave, Just read you r2-r6 upgrade - 2 minutes ago i just got caught out by the INACTIVE 600 in telnetparms so thanks for the tip about BEGINVATM.... Another one we just hit though that hurt us & you might like to add to your page. In FTP.DATA under v1.2, 'RETPD 0' meant no expirey date but under v2.6 it means exired immediately - very nasty - HSM's just been deleting loads of stuff we didn't want it to! Fixed by romoving the '0' or RETPD completely. Rgds, Jon.
A long time ago in a MVS upgrade far far away...