Messages

211

Report Indexing / Re: Unique key in CMOD

« on: August 07, 2012, 06:53:17 AM »

You could store your "alter table DDL" in an INSERT TRIGGER and activate that trigger when the magical number is almost reached. This (before) trigger checks for the table-switch and triggers the execution of the DDL. Not sure if that is going to work but it would be a nice experiment in your test-system.

This method would work.  We currently do a similar thing by propagating a trigger automatically everytime a new segment is created.

212

Report Indexing / Re: Can CMOD handle 'Channel Oriented Carriage Control'.

« on: July 27, 2012, 06:49:15 AM »

It would still have the CC bytes, it doesn't overwrite them

213

Report Indexing / Re: Can CMOD handle 'Channel Oriented Carriage Control'.

« on: July 26, 2012, 07:33:05 AM »

In addition, according to the manual it does look like CMOD should handle your Channel Oriented CCs.  Did you double check the LRECL?

214

Report Indexing / Re: Can CMOD handle 'Channel Oriented Carriage Control'.

« on: July 26, 2012, 07:27:41 AM »

We don't use EBCDIC Channel Oriented CC so I can't speak as to whether CMOD can handle that.  If it doesn't maybe you could use an input exit to transform the EBCDIC CC to Machine CC?  I know CMOD can handle that.

215

z/OS Server / Re: CMOD V850 : ARSLOAD & SQLCODE=-302

« on: July 20, 2012, 08:57:52 AM »

Glad you got it corrected.  Just as an FYI we ran into something similar soon after migrating to V8.5.  For reasons unknown one of our application group tables up and decided to change the datatype for one of the columns and any subsequent loads or queries failed with an SQLCODE=-301.  We had to do the same thing you did and recreate the table.

216

z/OS Server / Re: CMOD V850 : ARSLOAD & SQLCODE=-302

« on: July 18, 2012, 07:56:13 AM »

I don't think it's your ARSSEG table.  It's likely the table for your application group PHER.  Whatever index value you are attempting to insert into column 3 doesn't match what's defined for the column.  I see this is only the second load to that group, was something changed or modified before this load but after the original?

217

Report Indexing / Re: Indexing Entire Dataset as One Report Using Posting Date Only

« on: May 29, 2012, 05:35:17 AM »

  We do this all the time.  Try using BREAK=YES  on your index

This is correct.  We've learned that the OS/390 indexer requires at least one BREAK=YES or else it will break on every TRIGGER1 it finds.  We've been told this is considered working as normal for the OS/390 indexer.

218

z/OS Server / Re: How to know memory area on zos?

« on: May 25, 2012, 08:29:23 AM »

Is that purely a memory issue?  We don't use the generic indexer much but for the OS/390 and ACIF indexer the size of the load is tied more closely to the size of the temp directory defined in ARS.CFG.

219

z/OS Server / Re: Adding ARSIARSM to ISPF panel

« on: May 24, 2012, 05:57:51 AM »

Here is how it's set in our panels.  The monitor is placed in a submenu and uses selection CM:
&ZSEL = TRANS( &ZQ
CM,'CMD(%OFTCMOD1)'
DT,'CMD(%OFTDODAL T)'
DP,'CMD(%OFTDODAL P)'
DZ,'CMD(%OFTDB2 P)'
J,'CMD(%JCKSPF) NEWAPPL(CAZ1) PASSLIB'
SA,'CMD(%SAADMN)'
IPL,'CMD(%SYSIPL)'
' ',' '
X,EXIT
*,'?' )

OFTCMOD1 found in *.ISPF.SISPCLIB looks like this:

TRACE O
/*
ENV = V9    /* DB2 VERSION # */
"ISPEXEC LIBDEF ISPLLIB DATASET ID('ONDDODP."ENV".SDSNLOAD') STACK"
*/
"ISPEXEC SELECT CMD("EX "'IBM.ONDV85.SARSEXEC(ARSIARSM)'" EXEC")
PASSLIB NEWAPPL(CMOD)"
/* "ISPEXEC LIBDEF ISPLLIB" */
RETURN

220

z/OS Server / Re: Upgrade 8.3 to 8.4.0: No documents meet the search criteria

« on: March 15, 2012, 01:18:33 PM »

Be very careful when trying to disable the ODF feature.  The manual states that you can rename the arsuload exit on your HFS to prevent those messages from appearing.  We did this in test and it worked fine.  When we tried it in production it brought down all our instances, which was compounded by the fact that it resided on a read only directory.  Just be sure to test. It can be found in /usr/lpp/ars/bin/exits and IBM recommends renaming it to ARSULOAD.bak.  This info can be found in the Common Configuration Problems Manual.  That said, we ran with that message for years and it doesn't cause any issues so I seriously doubt that's your issue.
  As for your original question, hard to say what the problem is without more information.  Sounds like some configs got crossed in the upgrade.

221

MP Server / Re: Is DOC_NAME unique across AG's

« on: February 10, 2012, 08:46:16 AM »

It's doubtful that the DOC_NAME would be unique across AG's.  That's a counter that's internal to each AG so any number of AG's could contain the same DOC_NAME.

222

z/OS Server / ARSMAINT and OAM

« on: February 10, 2012, 07:37:27 AM »

I didn't want to hijack the other the other thread regarding document holds so I'm starting a new one. 
In the other thread Ed stated "- Because the application group has an expiration of LOAD - arsmaint (or arsadmin unload) is able to call OAM to delete the objects as well."

I was a little suprised to read this as I've been going under the assumption that ARSMAINT only touches cache and indexes.  Does ARSMAINT really delete OAM objects?  I suppose it's possible if CMOD is issuing an OSREQ DELETE command but there's no mention of this in the manual.  We have a couple of users who tend to mix up the use of Expire by Storage manager and Expire by load so this would be useful to know.

223

z/OS Server / Re: how to delete delete permission in application group using arsxml

« on: January 12, 2012, 10:02:02 AM »

Just reread your subject line.  Did you want to delete a users delete permissions?  If so, that's just an update of the permissions in the application group
e.g:

<?xml version="1.0" encoding="IBM-1047" ?>
<onDemand xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noName ........

 <applicationGroup name="AGGROUP" >
 <permission task="update" user="username" docDeletePerm="No"  />
</applicationGroup>
</onDemand

224

z/OS Server / Re: how to delete delete permission in application group using arsxml

« on: January 12, 2012, 09:22:53 AM »

I haven't done a delete yet but I believe it should just be something like:

ARSXML UPDATE -h archive -u user -p password -i "update.xml"

And update.xml would contain your xml:

<?xml version="1.0" encoding="IBM-1047" ?>
<onDemand xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noName ........

 <applicationGroup name="OPCREP" >
  <permission task="delete" user="username" <- your permissions/user you wish to delete />
 </applicationGroup>
</onDemand>

225

z/OS Server / Re: CMOD 8.5 IS OUT!!!!

« on: May 31, 2011, 12:34:12 PM »

We have ODF on 8.4.0.3 and we're upgrading to 8.5.  Since our ODF was a fairly small instance we decided it will be easier for us to just rebuild the ODF as a new install in 8.5 rather than trying to upgrade to 8.4 instance.