Messages

166

z/OS Server / PH31060 may cause an error in ARSUUPDX exit

« on: March 23, 2021, 09:54:53 AM »

PH31060 -                                                           
  ARSUUPDT FIELD ARSCSXITUPDTEXIT-FILENAME VALUE CHANGED IN VERSION 10.1                                                             
  PROBLEM SUMMARY:                                                   
  ****************************************************************   
  * USERS AFFECTED: All Content Manager OnDemand for z/OS 10.1   *   
  *                 and above using arsload -E and loading files *   
  *                 from the JES spool.                          *   
  ****************************************************************   
  * PROBLEM DESCRIPTION: When loading files from the JES spool   *   
  *                      and specifying the -E option to         *   
  *                      arsload, the arsuupdt exit              *   
  *                      ArsCSXitUpdtExit->pFileName parameter   *   
  *                      receives a pointer to a string that     *   
  *                      starts with 'DD:'.  Previously it       *   
  *                      pointed to a string containing a        *   
  *                      psudo-filename like                     *   
  *                      /arsa/tmp/MVS042.BPXAS.ADFOUT.STD.20110 *   
  *                      5.1804170016779814.ARD.                 *   
  ****************************************************************   
  ARGLOAD was inadvertently changed to pass the DD name as the       
  pFileName parameter when processing a spool files.                 
  PROBLEM CONCLUSION:                                               
  ARGLOAD is changed to pass the psudo-filename as the pFileName     
  parameter when processing a spool file. 


Had a report of loads failing.

(a) be sure to test the exit after applying this maintenance

(b) Level 2 might have a workaround

Ed

167

z/OS Server / PH31060 may cause an error in ARSUUPDX exit

« on: March 23, 2021, 09:53:38 AM »

PH31060 -                                                           
  ARSUUPDT FIELD ARSCSXITUPDTEXIT-FILENAME VALUE CHANGED IN VERSION 10.1                                                             
  PROBLEM SUMMARY:                                                   
  ****************************************************************   
  * USERS AFFECTED: All Content Manager OnDemand for z/OS 10.1   *   
  *                 and above using arsload -E and loading files *   
  *                 from the JES spool.                          *   
  ****************************************************************   
  * PROBLEM DESCRIPTION: When loading files from the JES spool   *   
  *                      and specifying the -E option to         *   
  *                      arsload, the arsuupdt exit              *   
  *                      ArsCSXitUpdtExit->pFileName parameter   *   
  *                      receives a pointer to a string that     *   
  *                      starts with 'DD:'.  Previously it       *   
  *                      pointed to a string containing a        *   
  *                      psudo-filename like                     *   
  *                      /arsa/tmp/MVS042.BPXAS.ADFOUT.STD.20110 *   
  *                      5.1804170016779814.ARD.                 *   
  ****************************************************************   
  ARGLOAD was inadvertently changed to pass the DD name as the       
  pFileName parameter when processing a spool files.                 
  PROBLEM CONCLUSION:                                               
  ARGLOAD is changed to pass the psudo-filename as the pFileName     
  parameter when processing a spool file. 


Had a report of loads failing.

(a) be sure to test the exit after applying this maintenance

(b) Level 2 might have a workaround

Ed

168

MP Server / Spectrum Protect client Version 8.1.8 on AIX platform exposes Java bug

« on: March 23, 2021, 09:40:16 AM »

https://www.ibm.com/support/pages/gui-dsmj-818-aix-client-fails-start-ans1579e-gskkmerrcryptoalgorithm-reported-dsmerror-log

GUI / DSMJ 8.1.8 AIX client fails to start with ANS1579E GSKKM_ERR_CRYPTO_ALGORITHM reported in dsmerror log

Resolving The Problem

This is resolved with fix for Java APAR  IJ17282 .

The fix was shipped in Java 8.0.5.40.

A link in the link above shows how to download the Java fix.

169

MP Server / Re: Issue configuring new environment

« on: March 20, 2021, 12:29:43 PM »

Hmmm.  By any chance?

https://www.ibm.com/support/pages/node/518695

Ed

170

MP Server / Re: Issue configuring new environment

« on: March 19, 2021, 03:06:01 PM »

No error message anywhere of any kind?

Ed

171

z/OS Server / Re: ARSOCKD gets CC 06 after DB2 v12 upgrade

« on: March 17, 2021, 05:15:34 AM »

where would I find my  omvs setting?
thanks
Bill

Don't worry about the OMVS settings now, I'd say that the -805 is the smoking gun.

First thing I'd do is run bind job SDSNSAMP(DSNTIJCL).

Ed

172

z/OS Server / Re: ARSOCKD gets CC 06 after DB2 v12 upgrade

« on: March 16, 2021, 09:30:00 AM »

Hi Bill - unfortunately rc=6 is about as generic an error as you can get.

Just taking a swag - what are your OMVS settings?   (D OMVS,L or D OMVS,O)

Do you start ARSSOCKD with the -v (verbose) option?

Are your parms listed in sysout?  If so append them here.

You could also list your LE parms and post them here using this format for the EXEC statement:

//STARTARS EXEC PGM=ARSSOCKD,REGION=0M,TIME=NOLIMIT,MEMLIMIT=10000M,
//  PARM='RPTOPTS(ON)/-S -I ARCHIVE -v'

Ed

173

z/OS Server / Re: RUNSTATS Behavior Change with Db2 V12

« on: March 12, 2021, 12:27:57 PM »

Text from the PTF for PH34239:


PH34239 -                                                         
  CMOD IS ENHANCED TO SPECIFY INVALIDATECACHE YES WHEN RUNNING   
  DB2 12 OR HIGHER.                                               
  PROBLEM SUMMARY:                                               
  ****************************************************************
  * USERS AFFECTED: All Content Manager OnDemand for z/OS 10.1   *
  *                 and above customers                          *
  ****************************************************************
  * PROBLEM DESCRIPTION: DB2 12 introduced a change in that      *
  *                      RUNSTATS no longer invalidates the DB2  *
  *                      statement cache.  This can cause        *
  *                      performance issues with CMOD            *
  *                      application group data tables.          *
  ****************************************************************
  * RECOMMENDATION: ARGMVSIE is changed so that if running on    *
  *                 DB2 12 or higher an INVALIDATECACHE YES      *
  *                 clause is added to the RUNSTATS command.     *
  *                 This will restore the pre-DB2 12 RUNSTATS    *
  *                 behavior.                                    *
  ****************************************************************
  DB2 12 introduced a change in that RUNSTATS no longer           
  invalidates the DB2 statement cache.  This can cause performance
  issues with CMOD application group data tables.                 

174

z/OS Server / Re: Job and/or Started Task ARSYSPIN CMOD z/OS V10R1

« on: March 12, 2021, 12:20:42 PM »

Eli - 

ARSYSPIN - there's not a whole lot to it.  You can easily cut 'n' paste the JCL from here:

https://www.ibm.com/support/knowledgecenter/SSQHWE_10.5.0/com.ibm.ondemand.administeringzos.doc/arsyspin.htm

If you want to make an enhancement request elsewhere on here, you could.

Fortunately, "ARSYSPIN" is a rather unique set of 8 chars and it's pretty easy to search on.

Ed

175

z/OS Server / Re: SSL on z/OS

« on: March 05, 2021, 04:00:16 PM »

Had a question posed to me:

But I came across following note on IBM site..
============================================================
SSL improves security by encrypting and decrypting data across the network. The encryption and decryption occur at the application layer, which consumes the additional processing cycles for both the sending and receiving systems. Therefore, consider using SSL only for sessions where it is needed. Consider adding additional processor resources on the Content Manager OnDemand server or clients to manage the increased overhead processing.
============================================================

So the question is, what about SSL and z crypto hardware?

If everything is set up correctly, yes the SSL processing should use the hardware.

More about when hardware gets used for SSL at https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.gska100/sssl2d3998602.htm . There is a lot of 'If things are" in there - meaning things have to be set up correctly.

On z/OS CMOD uses System SSL. On MP (Linux/Unix/Windows) it uses gskit. 

z System SSL lets you use a RACF keyring, a key database file (gskkyman), or a PKCS#12 file. Assuming you use SSL for other things, recommend putting the CMOD certificates in the same place as the SSL certs for the other things (RACF, kdb, or pkcs#12). Having your certificates in one place should make maintenance easier (e.g. expiring certs).

The CMOD ars.ini SSL_KEYRING_FILE identifies what the keystore is. CMOD just passes the value to SSL, and SSL figures out what it is. A RACF keyring would look like ARSUSER/KEYRING. A .kdb would look like /usr/lpp/ars/foo.kdb. A PKCS#12 token looks like *TOKEN*/token-name.

See the description of GSK_KEYRING_FILE at https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.gska100/sssl2api1065103.htm

Ed

 

176

z/OS Server / The End

« on: March 04, 2021, 09:50:39 AM »

Db2 V11 for z/OS EoS March 31, 2021

https://www.ibm.com/support/lifecycle/details?q45=Y500397H59081K65

Ed

177

Tips and Tricks / Re: Proof of Concept - Archiving the z/OS SYSLOG With ARSYSPIN

« on: February 25, 2021, 07:58:35 AM »

Hey Ed.  I just enabled the upload of .zip files.  You can edit your post and try again. 

-JD.

You da man.  Done.

Ed

178

Tips and Tricks / New method

« on: February 24, 2021, 12:27:48 PM »

Had a query about this topic, tried to download the attached file, nothing worked.

Reinvented the wheel, try this:

PARMLIB member:

 applgroup="MVSSYSLOG-AG"       
 appl="MVSCONSLOG1"             
*selform=(NODX2)               
*reportid=NODX2                 
 outsep=no                     
 jesclass=L                     
 capdskeep=yes                 
 dsnpfx=ARS.ARSYSPED           
 jobbreak=yes                   
 maxsfc=1                       
 maxdorm=10                     
*temppath=/u/odadmin           
 temppath=/ars/codwekcache     
 tempunit=vio                   
 odhost=n.m.o.p           
 odinstance=arch10           
 oduser=odadmin                 
 oduserpw=blahblah

//IEFPROC EXEC PGM=ARSYSPIN,REGION=0M                       
//STEPLIB  DD DISP=SHR,DSN=ARS.ARSV1010.SARSLOAD             
//         DD DISP=SHR,DSN=ARS.ARSV1010.USERLOAD             
//         DD DISP=SHR,DSN=DB2.V12R1M0.SDSNEXIT             
//         DD DISP=SHR,DSN=DB2.V12R1M0.SDSNLOAD             
//         DD DISP=SHR,DSN=DB2.V12R1M0.SDSNLOD2             
//ARSBIN   DD PATH='/usr/lpp/ars/V10R1M0/bin'               
//DSNAOINI DD PATH='/usr/lpp/ars/V10R1M0/config/cli.ini'     
//SYSIN DD DUMMY,DCB=(LRECL=80,BLKSIZE=80,RECFM=FB)         
//CEEDUMP DD SYSOUT=*                                       
//SYSPRINT DD SYSOUT=*                                       
//SYSOUT DD SYSOUT=*                                         
//ARSYLIST DD SYSOUT=*                                       
//ARSYPARM DD DISP=SHR,DSN=USER1.PRIVATE.PARMLIB(ARSYSPED)

Temp.zip.   It's a zip file of a local server which has the defs.   

Ed

             

179

Report Indexing / ACIF V4.6 goes EoS 12-31-2022

« on: February 24, 2021, 09:18:29 AM »

On z/OS where ACIF is ordered separately, be sure to include V4.7 when you order CMOD V10.5. 

(As of this writing, no EoS date yet for CMOD 10.1.)

Ed

180

z/OS Server / RUNSTATS Behavior Change with Db2 V12

« on: February 23, 2021, 11:02:33 AM »

As per my previous post default RUNSTATS behavior changed with Db2 V12.

This affects everything, not just CMOD.

I received the following on an issue that Db2 had over the weekend:

The dynamic statement cache for UPDATE was not invalidated during ALTER Table, so the invalid MSIB field for a varchar column caused SQL UPDATE to move large storage, which caused storage overlay and brought down Db2.

Customer can use RUNSTATS with INVALIDATECACHE on table space foo.foo to invalidate the statement cache and not to run ALTER statement to avoid additional abends.

Ed