ACR

To resolve this message:  #UBS043W: APPROACHING MAXIMUM NUMBER OF JOB ID KEYS. SPACE AVAILABLE FOR ONLY 5 NEW JOB ID KEYS.

The docs indicate :Either use the Reorganize History Utility (REORG HIST) to reorganize the History File into a larger file or create a new, larger History File using the UNIINIT program and the Copy History Utility (COPY HIST) to copy the data from the old file to the new one.

I am unfamiliar with how to navigate the ACR panels and assume there are batch JCL that can be used to perform the actions needed.  Our previous ACR admin used a job (many years ago) that invoked  PGM=UACUTIL as one of the steps to perform a reorg of the file. 

The idcams definition for the new file being copied to was:

DEFINE CLUSTER (NAME(SD0.ACR.PROD.UNIHF.REORG) -
UNIQUE -
SHR(3,3) -
NUMBERED -
VOLUMES(MXA120) -
RECORDS(00061000)) -
DATA(NAME(SD0.ACR.PROD.UNIHF.REORG.DATA) -
RECORDSIZE(1020 1020) -
BUFFERSPACE(10200) )

The input control statement for the job at that time was the following:

//UNIINP DD *

REORG HF 0000200000060000

I assume I would need to tweak things to make the job relevant for the current data in the file.  Is there batch job can I use to LIST the histories (possibly to identify and purge the ones not needed)?  

Am I on the right track, or am I way off the mark?

How do I get the questions in this thread responded to from ACR Tech Support?

From our ACR team:

Hello Bruce,

From your email I took this blurb.

“I am unfamiliar with how to navigate the ACR panels and assume there are batch JCL that can be used to perform the actions needed.  Our previous ACR admin used a job (many years ago) that invoked  PGM=UACUTIL as one of the steps to perform a reorg of the file. Am I on the right track, or am I way off the mark?”

Sorry to say you are not on the right track and your assumption is not correct. There is batch JCL but you have to create it through the online panels. Infogix does not supply canned JCL. The utilities that you are referring to like REORG or LIST HISTORY are all called from the base module UACUTIL. The cards that are generated and are complicated. They are not easy to manually edit.

For example. The REORG JCL has 2 options. You can REORG into itself or you can REORG into a NEW database. It would be difficult to try and change the IDCAMS section that you cut and pasted. To make sure you had exactly what is needed. Please don’t be fooled. We used IDCAMS. But they are special to Infogix. From your email. I cannot tell if you are using Infogix ACR Summary or Detail. If it  was ACR Summary when we INIT a HISTORY database. This isn’t a plain IDCAMS. We actually add a line to the VSAM file. So it’s not a plain IDCAMS DELETE / DEFINE.

If this is an emergency we could supply you with the JCL to REORG. But you need to be able to get around the ACR online panels to be able support the product.

I'm stepping in as the ACR admin while our current admin is out on medical leave.  I remember installing ACR summary over a decade ago.  Back then it seemed difficult to get specific admin tasks done.  Since the product still requires the use of multiple panels to generate the JCL needed for basic functions then it still is difficult.

It would be a great help to us (and I assume a great number of other customers) if you could provide example JCLs for specific functions along with documentation needed for the input parameters such as is done with most JCL driven products.    (The question I leave in my next comment posted will have an example.)

Our dept installs the products used in z/OS, but we don't use many of them, so to learn how to navigate through the ACR Summary panels requires finding one of our current Application Users so we can get their help.  But they never do Admin functions, such as file reorgs, because they don't have the security to delete and allocate the Prod files.  So a task like reorging a prod History file becomes quite a cumbersome thing. 

I'm leaving this comment for the sole purpose of helping describe the challenge we have with maintaining ACR Summary.  Most of our vendors solicit this kind of input to help make their products as user friendly as possible. 

I'll leave this comment separate from a specific question that I'll post in a little bit just so they don't get mixed up.

Bruce Jandernoa,  Auto-Owners Insurance Co.

In the JCL below that had previously been setup to reorg a history file.  I need help finding out how to determine what to use for the following:

 -What IDCAMS parameter to use in //STEP1 for the RECORDS(##########) that currently reads 'RECORDS(00061000)'? 

- What to use for the input on the UNIINP DD in STEP2 that currently reads  'REORG HF 0000200000060000'?

//*********************************************************
//* * UTILITY TO REORGANIZE ACR/S DATA BASE (UNIHF)
//*********************************************************
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=&OUT
//SYSIN DD *
DEFINE CLUSTER (NAME(SD0.ACR.PROD.UNIHF.REORG) -
UNIQUE -
SHR(3,3) -
NUMBERED -
VOLUMES(SYSP14) -
RECORDS(00061000)) -
DATA(NAME(SD0.ACR.PROD.UNIHF.REORG.DATA) -
RECORDSIZE(1020 1020) -
BUFFERSPACE(10200) )
LISTCAT ENTRIES(SD0.ACR.PROD.UNIHF.REORG) ALL
/*
//************
//STEP2 EXEC PGM=UACUTIL
//STEPLIB DD DISP=SHR,DSN=SD0.ACR.LOADLIB
//UNICF DD DISP=SHR,DSN=SD0.ACR.PROD.ACRCNTL
//UNIUF DD DISP=SHR,DSN=SD0.ACR.SUM.USEROPT
//SYSUDUMP DD SYSOUT=*
//SYSDBOUT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//UNIHF1 DD DISP=OLD,DSN=SD0.ACR.PROD.UNIHF
//UNIHF2 DD DISP=SHR,DSN=SD0.ACR.PROD.UNIHF.REORG
//UNIHRR DD SYSOUT=*,RECFM=FBA,LRECL=133,BLKSIZE=133
//UNIHFW DD UNIT=DISK,DSN=&&UACWORK,DISP=(,PASS,DELETE),
// RECFM=FB,LRECL=1200,BLKSIZE=12000,
// SPACE=(CYL,(10,10),RLSE)
//* JOB ID # OF HISTORYS
//UNIINP DD *
REORG HF 0000200000060000
/*
//UNITR DD SYSOUT=*,RECFM=FBA,LRECL=133,BLKSIZE=133
//SORTWK01 DD SPACE=(CYL,5),UNIT=DISK
//SORTWK02 DD SPACE=(CYL,5),UNIT=DISK
//SORTWK03 DD SPACE=(CYL,5),UNIT=DISK
//SORTWK04 DD SPACE=(CYL,5),UNIT=DISK
//SORTWK05 DD SPACE=(CYL,5),UNIT=DISK
//SORTWK06 DD SPACE=(CYL,5),UNIT=DISK
//IGZSRTCD DD DUMMY
//*
//************
//NEWNAMES EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
ALTER SD0.ACR.PROD.UNIHF -
NEWNAME(SD0.ACR.PROD.UNIHF.OLD)

ALTER SD0.ACR.PROD.UNIHF.DATA -
NEWNAME(SD0.ACR.PROD.UNIHF.OLD.DATA)

ALTER SD0.ACR.PROD.UNIHF.REORG -
NEWNAME(SD0.ACR.PROD.UNIHF)

ALTER SD0.ACR.PROD.UNIHF.REORG.DATA -
NEWNAME(SD0.ACR.PROD.UNIHF.DATA)
/*

I'll get into the details below on how to hand-code the JCL, but as an shortcut, those values are automatically calculated and inserted into the JCL when the Reorg JCL is created via the ACR panels. That way you wouldn't need to worry about the syntax nor calculations noted below. 

To hand-code the values in the JCL, I'll answer the second question first. The answer of the second question is needed to explain the first question:

The UNIINP DD line is read as two 8-digit values. I put one value in bold and the other in italics:

REORG HF 0000200000060000

The first 8 digits (00002000) indicates the number of estimated unique job IDs that will be stored in the database. The last 8 digits (00060000) indicates the expected number of history items stored across all jobs. As a side-note, by dividing the two values, we can tell there will be 30 histories stored per job (on average). This extra implied value will also be used in our calculation.

Since your error message is showing a small about of Job IDs remaining, increasing the first 8-digit value (00002000) would be the appropriate course of action. It's also recommended to increase the second 8-digit value (00060000) to keep the ratio at 30 histories per job. This is the ratio that we calculated in the prior paragraph. For example, if you increase the maximum jobs to 00003000, then increase the histories to 00090000:

REORG HF 0000300000090000

To update the RECORDS line in the IDCAMS, take your new maximum histories and add 0.5% to it. This is a close approximation of what the Reorg panels calculates. It looks like your current JCL was also hand-coded, since the 00061000 value is well above the value the panels would have used (00060065). It's better to overestimate than to underestimate this value. Following the same example above, the estimated value would be:

RECORDS(00090450)) 

Gerard,

Thanks for the good explanation.  Using the parameters you provided (and fixing the record length that somehow got switched from 9020 to 1020 in the Idcams step) helped me reorg the file successfully.

I appreciate the help.

Bruce Jandernoa

Bruce, here's additional information from Gary Berg:

I completely agree with you that examples of JCL would be of great help. I have been on the ACR team for 22 years. In those years, I have seen great changes in our documentation. I have attached a chapter from a Summary User manual from Rel3.4. It was written on 06/09/2006. It's called JCL and Control statements. This section was delete from the USER manual in 2006, I can tell you, I was not asked about it. This section has not been updated since then. Truthfully, we have not had much call for JCL examples since then from our customers.
One thing I was thinking about that might help you with your support of ACR Summary. Is there a chance that you might know the HIGH LEVEL prefix of your co-worked that you are stepping in for? If you do, If you could find their PROCLIB and do a PRINT LIST. Send it to me. I could go through it and identify what JCL you do have. If they did not change the default names. I should be able to ID a lot of them. For example SUMINIT – Would be the default name for the data base initialization. You mention the List History report earlier. The default name for that is SUMHFL. So maybe your co-worker has generated the JCL already. We can ID it and you could use that? I do not think they will be updating the section in the User manual and adding it back anytime soon.
I will add your comments for our Customer Feedback about the documentation.
Thanks Gary

Attached files

ACR_SUMM_OLD_JCL_chapter (002).pdf

Gary (from Brenda),

I appreciate your understanding of the need for JCL documentation.  I wasn't able to open the link (maybe due to security on our end)  I would love to have access to that PDF.  Is there any other way I can view it?

Maybe it would be helpful for the decision makers at INFOGIX to understand more of how customers like us operate with other products. 

Here at Auto-Owners Insurance Co. we share everything, NOTHING is individualized.  Anything a previous admin has done is kept in a specific utility JCLlib named for that product so that the next admin doesn't have to reinvent the wheel.  Every function that has previously been performed is saved in that utility JCLlib.   For load-and-go products like ACR Summary, many of the admin functions (related to the SYSTEMS, not the applications) are often only performed a few times a decade.  In that time period the Admins change without really having a good grasp of how to use the product.  Why would they need to know how to use the product if they are only occasionally required for the admin functions (as a opposed to the users of the applications of the product)?  

Gary's suggestion for how to help me if I could remember the HIGH LEVEL prefix of my co-worker leads me to the other challenge with how ACR acts.  Since you can't even get into the panels without having the supporting files created there is no ability to have certainty about the purpose of any of them if they were built by other users.  We would have to get quite clever at naming conventions for sharing the files to provide certainty that ACR won't blow away members of the files that have been previously used by a different admin.  

To answer Gary's question, here ACR is setup to create the supporting files using our userid's as the beginning prefix.  Those files are deleted after months of no use.  The files for Bryan, the Admin who is out on medical leave,  are gone. 

I don't believe He has really done much with ACR other than install r4v9 in 2016.  He probably would have been going through the same process I did to figure out how to reorg the file.

I'll repeat the question here that I have at the top - Is there any other way I can view the PDF from the Summary User manual from Rel3.4.? 

Hi Bruce,

I just emailed you the PDF.