Messages

1

z/OS Server / Re: Decoding the "perms" column?

« on: August 02, 2022, 02:23:50 PM »

What I personally do for these "cryptic" fields- is pick one row, make a change in the admin, then see what changes..via query. and note it.

This is what I've done.  The PERMS column is a 2-byte binary field.  The second byte remains the same as posted above with the exception of the Fields value which is now on bit-5.  There is also bit-4 which seems to be "on" whenever multiple values are selected.

Finally, the first byte contains the Full Report value in bit-7.  Here's the bit breakdown for the 2 bytes.

8   4   2   1   8   4   2   1   8   4   2   1   8   4   2   1               
0   0   0   0   0   0   0   0   0   0   0   0   1   1   1   1   000F   Access+Admin+Fields         Authority
0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   1   0001   Access         
0   0   0   0   0   0   0   0   0   0   0   1   1   0   0   1   0019   Access+Fields         
0   0   0   0   0   0   1   0   0   0   0   1   0   0   0   1   0211   Access+Full Report         
0   0   0   0   0   0   1   0   0   0   0   1   1   1   1   1   021F   Access+Admin+Full Report+Fields         
0   0   0   0   0   0   0   0   1   0   1   1   0   0   0   1   00B1   Access+Public+View         Named Queries
0   0   0   0   0   0   0   0   1   1   0   1   0   0   0   1   00D1   Access+Private+View         
0   0   0   0   0   0   0   0   1   0   0   1   0   0   0   1   0091   Access+View         
0   0   0   0   0   1   1   1   0   1   0   1   0   0   0   1   0751   ALL         
                                                            
                                                            
                                             * All zeroes = *NO ACCESS*

2

z/OS Server / Re: Decoding the "perms" column?

« on: August 01, 2022, 11:26:35 AM »

Here's what I have from a previous release for the ARSFOLPERMS table:

Bit-8 = Access Flag
Bit-7 = Fields Flag
Bit-6 = Admin Flag
Bit-3 = Public Flag
Bit-2 = Private Flag
Bit-1 = View Flag

Bits =8,7,6 OFF = NO ACCESS

3

z/OS Server / Decoding the "perms" column?

« on: August 01, 2022, 11:21:46 AM »

Has anyone been able to decode the bit values of the "perm" column found accross several of the CMDO tables?

I figure I can probably decode by updating each value and displaying the row for the particular table but thought someone may have already done this?

4

OD/WEK & JAVA API / Re: CMOD/ICN view Line Data report via HTML5 viewer

« on: March 30, 2021, 11:01:18 AM »

Note that this installation is on AIX.

My basic process was to upgrade to the latest ODWEK (10.1.0.7) as the HTML5 viewer is included in the update (I was running with ODWEK 9.5).  As you probably already know, ODWEK is no longer provided separately but is part of the CMOD install tar installation.  The readme.txt file included in the CMOD (untared) installation directory details some additional steps required for the new release (https://cmod.wiki/dox/CMOD-v10.1-README.txt).

Steps taken:

1.   Download and install CMOD 10.1 base code (/opt/IBM/ondemand/V10.1) <=== may not be required if already installed.
2.   Download and install CMOD 10.1.0.7 from FixCentral
3.   Update ICN configuration (configmgr.sh) and change ODWEK installation directory to newly installed release (/opt/IBM/ondemand/V10.1/www) then build and deploy
4.   Included in the CMOD installation readme.txt:
     a.   Copy /opt/IBM/ondemand/V10.1/jars/gson-2.8.1.jar to /opt/IBM/ondemand/V10.1/www/api
     b.   Update WAS configuration and add /opt/IBM/ondemand/V10.1/jars/gson-2.8.1.jar to CLASSPATH
     c.   Update CLASSPATH (LIBPATH) in WAS to /opt/IBM/ondemand/V10.1/www
5.   Install GSKIT8.  Instructions included in ODWEK installation readme.txt.  This was an important step for me as ICN was unable to open the repository without it.
6.   Update ICN Customer Property ODWEK_INSTALL_DIR to new /opt/IBM/ondemand/V10.1 directory

To activate the HTML5 viewer:
1.   Create a directory in the WAS infrastructure to hold the new viewer contained in LineDataHTML5Viewer.zip (e.g. <WAS install>/AppSrv01/installedApps/TEST/navigator.ear/navigator.war/viewers/LineDataViewer)
2.   Unzip the /opt/IBM/ondemand/V10.1/www/viewers/LineDataHTML5Viewer.zip file into the …/navigator.war/viewers/LineDataViewer directory previously created

3.     Finally, update ICN Viewer Map using ICN admin to use Line Data HTML Viewer

I've been able to view line-data reports in both Edge and FireFox (something I was never able to do with the java line data applet  )

Of course, this is a summary of the install/implementation process.  There are many details left out such as WAS cleanup, bounce, etc.

5

OD/WEK & JAVA API / Re: CMOD/ICN view Line Data report via HTML5 viewer

« on: March 29, 2021, 10:51:59 AM »

I was able to get the HTML5 data line viewer working with ICN 3.0.6 and ODWEK 10.1.0.7 and using Edge/Firefox for vowing line data output.  If anyone is interested, let me know.

6

z/OS Server / Re: CMOD 10.5 Release Notes

« on: January 16, 2021, 09:04:34 AM »

FYI, I think you need to use ShopZ to order

7

z/OS Server / Re: Needs Clean SMP/E Zones

« on: January 14, 2021, 10:39:49 AM »

When I tried to install 10.5 in a zone that had a previous CMOD release I could never get it to work.

It never cleaned up properly the old release.

So I installed 10.5 in a fresh SMP/E.

Ed

I always install into a new zone in order to preserve and maintain multiple releases.

8

z/OS Server / Re: Enhanced Retention Management and expiration

« on: December 23, 2020, 08:13:21 AM »

It would not matter if you use the BETWEEN clause since every row being updated would contain the same ODCREATS value.

I think a better solution for me would be to change the MANAGEMENT CLASS in the OSM_OBJ_DIR for each of the objects I"m interested in changing.  ODMCNUM can be matched to an entry in CBR_MGT_CLASS_TBL correspoinding to the new MANAGEMENT CLASS and thus new retention.  Your thoughts?

9

z/OS Server / Re: Enhanced Retention Management and expiration

« on: December 22, 2020, 01:32:45 PM »

I've run into a -803 when trying to update ODCREATS.  I created a global temporary table containing all the rows I wish to update in ODCREATS since there may be multiple objects I need to update.  When using an UPDATE statement and trying to SET ODCREATS = CURRENT TIMESTAMP + 5 YEARS, I receive an obvious +803 due to a UNIQUE index on the OSM_OBJ_DIR table with the ODCREATS column.  Since the UPDATE is going to process several rows from AND since the CURRENT TIMESTAMP + 5 YEARS value is going to be the same for every UPDATE, then hence the duplicate primary key on index OBJDIRX1.

Not sure how I can get around this unless updating a single row at a time(?)

Note I'm using DSNTEP2 to update the table and thus a single UPDATE statement execution.

10

z/OS Server / Re: Enhanced Retention Management and expiration

« on: December 19, 2020, 08:41:12 AM »

Thanks for describing the environment in good enough detail so we can understand the problem better.

As I understand, ARSMAINT takes care of the indexes and OAM built in life cycle management (OSMC) is used to expire objects. In this case, again, depending on the situation you have different options:

I would definitely go with updating the ODCRETDT/ODPENDDT attributes such that OSMC when inspects the objects avoids expiring them. Just remember to restore to normal.

for example ODSCRETDT is 2020-01-01 and you want this object to have a +6 months extension on top of the original. You can run a DB2 command on the object directory to modify ODCREATDT to ODCREATDT + 6 months and ODPENDT to CURRENT DATE; this will ensure OSMC processing looks at the object in next cycle and gives it new expiry.

You must test this first and observe different use cases.

I have done this a lot but it could be dangerous if you are not sure what you are doing.

Thanks again.  I could not find the ODCREATDT (nor ODSCRETDT) column you're referring to.  I suppose you're referring to ODCREATS in the OSM_OBJ_DIR table?  I did find ODPENDDT in the same table though.  Another question is, if I can successfully update the dates as you specify and OAM does retain the objects for longer periods, how do I update the indexes to prevent ARSMAINT from expiring them as well since without "both" I would not be able to retrieve the documents from within CMOD?

11

z/OS Server / Re: Job to delete out files in the /tmp directory

« on: December 18, 2020, 09:13:04 AM »

We have a CRON job/command that performs clanup automatically for any file older than 7-days (-mtime +7). 

0 0 * * * find /tmp/ -type f -mtime +7 -exec rm -v {} \; > /tmp/tmp_rm.txt & 

12

z/OS Server / Re: Enhanced Retention Management and expiration

« on: December 18, 2020, 08:53:44 AM »

Thank you for your responses.

We assign storage nodes using the ARS.RSADUPDT exit which analyzes the number of Days coded in the "expire in" field of the AG definition.  Based on the number of days coded, there is an assigned storage node with the appropriate management class assigned to it.  We then run OSMC automatically to expire objects based on their assigned expiration (no DFHSM).  We also run nightly ARSMAINT to expire there as well.

Now we do not want to change that process and do not wish to change any of the current object's expiration dates.  All we want to use ERM is to retain documents "already loaded" to a different date.  We often receive requests from the users that they would like to retain reports that, for example, expire after 90-days, to now expire after 5-years.  I suppose that we could then place a HOLD on all of these reports but that would mean we would need to "remember" to remove the holds individually, after 5-years.  Does not seem like ERM is the right solution for this but rather some in-hour grown solution?

Your thoughts and comments are welcomed.

13

z/OS Server / Enhanced Retention Management and expiration

« on: December 16, 2020, 07:44:39 AM »

We're embarking on implementing ERM soon.  As I understand it, ERM retains documents by placing HOLDS and not by placing an expiration date on the document.  It is also my understanding that you must remove expiration processing currently in place (we currently use OAM for storing our reports).

So if t his is the case then how will reports that do not contain a HOLD, expire under notmal circumstances?  How do I control certain reports' expiration dates as I do using OAM today?  Will I lose this capability?

14

z/OS Server / Re: OAM Object Name Reference

« on: April 07, 2020, 01:15:56 PM »

So when using Expiration Type of "Storage Manager" on z/OS CMOD, you must either use the ARSEXPIR or ARSEXOAM utility to expire indexes.  One uses SMF data the other uses some sort of DB2 table.  Not familiar with either of these.  Can anyone elaborate on the benefits if any? 

15

z/OS Server / Re: OAM Object Name Reference

« on: April 07, 2020, 08:40:09 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)

That would make sense.  Unfortunately all of our AGs have Expiration Type of Load and Expire in ## days specified.  And there's no way to update the Expiration Type without extracting/reloading the documents into a new AG.  This is becoming more and more of an undoable task -- at least for us(me).  It would seem that my solution is the same that I established some time ago -- unload/reload documents from one AG to another (no update in place here).