Author Topic: 10.1 Release Notes  (Read 15268 times)

Nolan

  • Full Member
  • ***
  • Posts: 152
    • View Profile
Re: 10.1 Release Notes
« Reply #30 on: April 28, 2020, 07:33:48 AM »
Adding to the stricter rules. 

Comments must be /* comment */   - No space between forward slash and the asterisk.

The error message was
ARS5481I INDEX1='SEC_ID',FIELD1,(TYPE=GROUP,BREAK=YES)                / *SEC ID */
ARS5488E INVALID INDEXING PARM. ERROR OCCURS NEAR BREAK


The issue was the comment!!!   

« Last Edit: April 29, 2020, 05:23:57 AM by Nolan »
J.

#zOS #AIX #Windows #Multiplatforms
#DB2 #TSM #ODF #zODF #ODWEK
#CapacityPlanning #AFP #ReportDistribution
#Finance #ICN

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
APAR for easing migration of exits
« Reply #31 on: August 05, 2020, 01:40:10 PM »

Problem summary

****************************************************************
* USERS AFFECTED: All Content Manager OnDemand for z/OS 10.1   *
*                 and above customers                          *
****************************************************************
* PROBLEM DESCRIPTION: When calling 31-bit arsusec and         *
*                      arsuperm, there is no DB2 connection    *
*                      established when the exit is invoked.   *
****************************************************************
Although not documented as part of the arsusec and arsuperm
APIs, it so happened in 9.5 and below that the exits were
invoked with a DB2 connection.  The support in 10.1 for calling
the 31-bit exits did not invoke the exits with a DB2 connection.
In order to ease the process of upgrading, support is being
added to allow the arsuperm and arsusec exits with a DB2
connection established.

Problem conclusion

A new ars.cfg setting, ARSMVS_EXIT31_DB2_SECPERM, is being
provided.  If specified as ARSMVS_EXIT31_DB2_SECPERM=1, the
arsusec and arsuperm exits will be invoked with an ODBC DB2
connection.  Note that these will be additional DB2 batch
connections above that implied by ARS_NUM_DBSRVR.
#zOS #ODF

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
Problem With The MAXPARTITIONS Calculation
« Reply #32 on: February 17, 2021, 11:55:13 AM »
https://www.ibm.com/support/pages/apar/PH23110?mhsrc=ibmsearch_a&mhq=ph23110


Error description
For an application group, if a new index field is added or if
an existing filter field is changed to an index field ARSSOCKD
will abend under the following two conditions:
1) The existing tablespaces are non-UTS.
2) ARSMVS_DB_DSSIZE=n in ars.cfg

Also, its possible that the tablespace could be incorrectly
created with 1 for MAXPARTITIONS. Note: This APAR will only
specify the correct MAXPARTITONS for new table spaces. The
arstblsp commmand can be used to close the existing table and
cause a new tablespace. Alternatively, an ALTER TABLESPACE
can be used to increase the MAXPARTITIONS.
#zOS #ODF

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
PH31060 may cause an error in ARSUUPDX exit
« Reply #33 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
#zOS #ODF

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
Re: 10.1 Release Notes
« Reply #34 on: March 23, 2021, 04:25:24 PM »
Using 31-bit COBOL exits?

New DD def per the ++ACTION HOLD

++HOLD(UI74251) SYSTEM FMID(H272A10) REASON(ACTION) DATE(21062)     
  COMMENT(                                                           
  New DD definition to be added:  ARSSYSOU.     
                   
  Changed DD definition: SYSOUT as used by the CMOD. 
               
  This fix changes the LE runtime options for 31-bit exits.   
     
  Previously, any 31-bit exit COBOL DISPLAYs appeared in SYSOUT.
   
  With this change 31-bit exit COBOL displays will now appear in     
  the ARSSYSOU DD definition.               
                       
  This change fixes a problem with a 64-bit LE enclave interfering   
  with 31-bit LE enclave usage.   
                                   
  It does this by separating 31-bit enclave usage of the MSGFILE     
  with the default of SYSOUT from the 64-bit LE enclave usage of     
  the MSGFILE with the default of SYSOUT.     
                       
  This change will cause any 31-bit exit COBOL DISPLAYs to now       
  appear on a DD of ARSSYSOU instead of a DD of SYSOUT. 
           
  If customers are relying on the output from the exits appearing   
  on the SYSOUT DD, the ARSSYSOU DD needs to be used instead.).
   
#zOS #ODF

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
Malformed PTFs Were Shipped By IBM From Boulder
« Reply #35 on: April 14, 2021, 10:42:05 AM »
Red Alert

PTF service orders from 4 December 2020 to 10 December 2020 need to be reviewed.

CMOD PTFs are on the list.

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

Ed
#zOS #ODF

ibmarthin

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
Re: 10.1 Release Notes
« Reply #36 on: June 16, 2021, 01:15:12 AM »
CMOD V10.1 is compiled with option ARCH( 8 ), meaning a z10 processor or newer is required.

Running on any processor prior to a z10 is likely to result in a S0C1.

Note:  z/OS 2.2 pre-reqs a z10 processor.

Also, CMOD V10.1 is compiled with the option TARGET(zOSV2R2).

Bottom line:  don't try to run CMOD V10.1 on z/OS 2.1.

Ed
Is this still the case. We have other problems with 10.1, OAM issues, but not S0C1.
Release                  z/OS 2.1.0 (SPLevel 7.2.1)   

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
Re: 10.1 Release Notes
« Reply #37 on: June 18, 2021, 06:36:27 AM »
Is this still the case. We have other problems with 10.1, OAM issues, but not S0C1.
Release                  z/OS 2.1.0 (SPLevel 7.2.1)   

Yes.  I hope you can get to z/OS 2.2.0 soon.

Ed
#zOS #ODF

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
Re: 10.1 Release Notes
« Reply #38 on: August 30, 2021, 08:18:52 AM »
Customers installing the PTF for PH31060 should also install PH36829 at the same time.

This affects customers at both the 10.1 and the 10.5 level.

Ref (a):  https://www.ibm.com/support/pages/apar/PH31060

Ref (b):  https://www.ibm.com/support/pages/apar/PH36829     

PH31060 fixed an incompatibility issue with the ARSUUPDT exit. 

Unfortunately, at the same time it exposed an issue in some exits which was then resolved by PH36829.

Note the following in the HOLD ACTION for PH36829:

This sysmod updates INSTALLDIR/bin/exits/arsusec, arsuupdt, and   
     arsuupdt. If the installation has copied those to another         
     location, they will need to get copied again.   
                 
                                                                       
This sysmod updates SARSINST(ARSUSEC, ARSUPERM, and ARSUUPDT) to 
     allow them to call a COBOL program. 

If you have been compiling   
     SARSINST(ARSUSECC or ARSUPERC) solely in order to call a COBOL   
     program named ARSUSECX, the supplied bin/exits/arsusec and       
     arsuperm will now do that without needing to compile ARSUSECC or 
     ARSUPERC.

If you have been compiling SARSINST(ARSUUPDC) only in   
     order to call a COBOL program named ARSUUPDX, the supplied       
     bin/exits/arsuupdt will now do that without needing to compile   
     ARSUUPDC. 

If you are compiling SARSINST(ARSUSECC, ARSUPERC,     
     and/or ARSUUPDC) for other changes, the changes will need to get 
     reworked in the updated SARSINST(ARSUSECC, ARSUPERC, and/or       
     ARSUUPDC).


In short, the PTFs for these two APARs should be installed together.

Of course, ensure any exits are tested before upgrading to production.
#zOS #ODF

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1199
    • View Profile
Re: 10.1 Release Notes
« Reply #39 on: January 26, 2022, 12:03:18 PM »
The end all and be all doc for 10.1 log4j remediation is this techdoc:

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

Highly recommend the 10.1.0.10 fixpack no matter whether you're directly affected or not as it completely shuts down questions about log4j and CMOD.

https://www.ibm.com/support/pages/how-do-ptf-numbers-relate-content-manager-ondemand-product-version-numbers-and-maintenance-fix-packs

Reminder - V10.1 goes EoS all platforms April 30th, 2022.

Ed

#zOS #ODF