Messages

1

z/OS Server / Re: Tablespace / Index Creation using ars.cfg DB2 Parameters

« on: May 13, 2021, 07:39:09 AM »

We work with our Storage unit and use SMS rules.  Naming conventions of the Database conforms to the SMS rules.  Same is true with OAM DBs for Retentions.  Other than the initial ARS* Tables, All the Index Data Tables are "automatically" controlled. 

2

z/OS Server / Re: os/390 indexer fails after upgrading to v9.5

« on: April 23, 2021, 11:24:40 AM »

Like Ed said, do you use input exits?  We went from v8.5 to v9.5 and the API calls in the Input exists had changed.  Needed to change every Input exit we wrote to accommodate.

3

z/OS Server / Re: cmis:creationDate

« on: April 15, 2021, 11:14:42 AM »

I would look at the definitions in the Admin client for both the Folder and the AG, not querying with a GUI interface.

4

z/OS Server / Re: cmis:creationDate

« on: April 15, 2021, 09:48:10 AM »

Curious what you are querying.  Not an ARS* table.  Indexed data table?  CMOD's internal date is starting at that date.  Might be an empty query. 

Any DB2 table defined for CMOD can have a DCLLIB built with SPUFI.  (IBM MAINFRAME side).  I use that to extract all of the columns of a table and the datatype for each.

5

z/OS Server / Re: os/390 indexer fails after upgrading to v9.5

« on: April 15, 2021, 09:39:56 AM »

Did you update the APP after the upgrade?  I've had problems when changing the ACIF to 390 and back again.  inserted parameters and didn't remove them.  Don't see them in the "indexing information" but could see it in the "Summarize" option. 

Also, using the Wizard, didn't seem to populate the "Data compression" value in "load information".   

Maybe help.  We load just fine however.

6

z/OS Server / Re: CMOD Retention based on GDG like versions

« on: January 04, 2021, 01:17:55 PM »

We just err on the side of saving a couple extra.  Generally, the number of GDG's is actually synonymous with Weeks, Months, days. (as a rule).  With CMOD compression, it's just easier to keep a couple of extras.  5 Daily GDG's, we would save a week or 2.  Many times the users will have a "oh, I wish I had just ONE more..."  Remember that it doesn't need to be obvious to the user.  You can keep a Month of them, but had the default date range on the FOLDER be 14 days.  If they don't change the date they think that is all there is.  Easier to keep a couple of extra's than try to RESTORE that needed report from "Somewhere".  Make sure the Folder is sorting on the appropriate Date Descending so they seem them in descending (newest to oldest).  Add a defaulting LOAD DATE if needed. 

7

z/OS Server / Re: Doing a mask change on report retention

« on: December 21, 2020, 09:59:59 AM »

Are the reports being expired by oam or CMOD?  (days in the AG/APP)?

8

z/OS Server / Re: OAM Object Name Reference

« on: April 07, 2020, 07:52:15 AM »

When we use the "expire in xxxx days" we store all reports in a "forever" OAM.  That way full control is within CMOD.  When we let OAM expire the reports, we change the Expiration Type to "Storage manager" and "life of Data and Indexes" to NEVER EXPIRE. there is an OAM Delete Trigger for DB2 that inserts an entry for CMOD to delete the Index Data Records using the ARSMAINT job (Doesn't help after the fact, however)

9

z/OS Server / Re: OAM Object Name Reference

« on: April 06, 2020, 12:22:21 PM »

First of all, I agree with Greg (he's my supervisor  ) .
We have traditionally used various OAMs: 1year, 3years, 10years, etc.   Even if that would work, we wouldn't want to effect all of the other reports stored in that OAM - just the one APPLICATION Group in question.

if the report's retention were to be extended, we would only change all of the OAMs objects related to that ONE Application Group.  We would then change the CMOD Storage Set to then point to ANOTHER OAM with the desired, longer retention.  Future reports would then be stored there. 

10

z/OS Server / Re: OAM Object Name Reference

« on: April 06, 2020, 12:00:27 PM »

I believe you are mis-interpreting the SYSIN card.  This is not a "change" to a management class, but a fully qualified REFERENCE to the document in question.  Remember they are paired.

OND.COLL.M1TEST.SGD03M1T.MCDM01     GAA.L4.FAAA <===
OND.COLL.M1TEST.SGD03M1T.MCDM01     GAA.L4.FAA1 <===

11

z/OS Server / Re: Maximum application groups mapped to a folder?

« on: April 03, 2020, 12:01:26 PM »

Curious what a "large number of applications" would be? We've hit a high number of Index Data Tables when doing a search in a folder.  (160+ I seem to remember).  Forced to consolidate them. 

Gets a 13 record error "DB Error: {DB2 FOR OS/390}{ODBC DRIVER}{DSN11015}   DSNT408I SQLCODE = -101, ERROR:  THE STATEMENT IS TOO LONG OR TOO COMPLEX        DSNT418I SQLSTATE   = 54001 SQLSTATE RETURN CODE                                 DSNT415I SQLERRP    = DSNXOEA SQL PROCEDURE DETECTING ERROR                      DSNT416I SQLERRD    = -55  0  0  -1  0  0 SQL DIAGNOSTIC INFORMATION             DSNT416I SQLERRD    = X'FFFFFFC9'  X'00000000'  X'00000000'  X'FFFFFFFF'                  X'00000000'  X'00000000' SQL DIAGNOSTIC INFORMATION                      ERRLOC=5:10:2 -- SQLSTATE=54001, SQLCODE=-101, File=arsdoc.c, Line=2997"

12

z/OS Server / Re: OAM Object Name Reference

« on: April 03, 2020, 10:16:57 AM »

It's been a couple of years since I had to do this.  My comment in the JCL  explains it.

THE WAY OAM IS CONFIGURED, THE EXPIRE PROCESS "CHECKS" WITH
THE MANAGEMENT CLASS FOR EXPIRATION.  THIS IS "TRUMPED" IF
THE (ODEXPDT) COLUMN IS OTHER THAN THE DEFAULT.

13

z/OS Server / Re: OAM Object Name Reference

« on: April 02, 2020, 12:37:32 PM »

I tried to provide a bit more detail on the relationship of oam document store.  I've attached a PDF with examples.  Hope this helps.

14

z/OS Server / Re: Any Migration guides from R9.5 to 10.1

« on: February 24, 2020, 11:39:19 AM »

I also suggest upgrading the CMOD System log, if you have an older Instance. (maybe before v9.5).  You can tell by looking at the System Log AG.  The "msg_text" field on older versions is 254 characters.  The new one is 2000 var.  In the document it is "Optional".  If you don't upgraded it, the end of line in the Message is truncated.  Also adds DB2 Timestamp columns in addition to CMOD date/timestamps.

https://www.ibm.com/support/pages/upgrade-guide-content-manager-ondemand-server-v1010

Optional, but recommended. Update the System Log and System Load application groups and folders to support new style dates.

Important: Once this is performed, older clients (prior to V9.0.0) will not be able to query the System Log or System Load folders.

Note: When the System Log and System Load application groups are updated, the current table will be closed and a new one will be opened once a new message or load is generated.

Note: Running these update commands will remove any user/group specific folder fields that have been defined for the System Log and System Load Folders. Customers will have to add the user/group specific folder fields again after the update is done.
Update the System Log application group and folder:

arssyscr -I instance_name -l -u

Update the System Load application group and folder:

arssyscr -I instance_name -a -u

15

z/OS Server / Re: ARSYSPIN output order doesn't match output queue

« on: January 24, 2020, 07:48:16 AM »

Well I know that the PC fat client allows the "Full Report Browse" option.  That will allow the user to view the entire load as one document and not broken out.  In playing a bit it was discovered that ICN doesn't support that feature.  You've gotten me interested in looking into the CICS Viewer though.  That is being used here.  Didn't know anyone else used it.  Have to see if "Full Report Browse" is supported.
Another option would be to load JES back into another Application using ODF.  It seems that you've altered the original SYSOUT Application to break on STEP (doesn't happen for us). 
Using ODF to spool it back out, loading it into another one, you could change that application to NOT BREAK on step.  We use that procedure to overcome many challenges.