Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - J9CMOD

Pages: [1] 2 3
z/OS Server / Re: Manifest print style
« on: June 15, 2018, 11:09:10 AM »
Thanks scottnys.
Your shop sounds a lot like ours.
Yes, we have customized exits for a all the reasons you mentioned, plus a few more.  From what I read in the manuals, etc, I figured it was an issue with the exit not passing the information to the manifest exit, but was trying to avoid having to change our exits.  We have 4 different exits to handle the scenarios we need, and changes to our Cobol programs take several weeks to get implemented in Production. 
I have put this issue on our back burner, to re-visit when we are more stable, and am using the work around in the meantime.  All the details you supplied will be helpful in my documentation - thanks for taking the time to respond!

z/OS Server / Re: Manifest print style
« on: June 12, 2018, 05:48:45 AM »
May not be the best solution, overall, but I found a work-around for us.
(In short) since the output I was working with was always the same size, I set up our email system to accept a specific number of lines for them, which forces a new page before the manifest.
Thanks for your suggestion, though!

z/OS Server / Re: Manifest print style
« on: June 11, 2018, 08:30:01 AM »
Yes, we have that PTF applied.  I guess it doesn't fix the problem for us.

z/OS Server / Re: Manifest print style
« on: June 11, 2018, 08:28:32 AM »
Thanks Greg, I have my Production Control resource checking now.  I'm pretty sure we have the same "cause" as you; I'll let you know. 

z/OS Server / Manifest print style
« on: June 10, 2018, 03:50:11 PM »
We have a distribution that is set up to print a number of output sets, when available.
That works great.  However, when I add the manifest, it does not start at the beginning of a new page.
I've tried several combinations of customer variables, and nothing works right.
Does anybody know of a parm, or something, that we can set so the manifest always prints at the top of a new page.

-  We are using an email system external to CMOD, so all bundles are sent to the output queue.
-  All Report IDs within the bundles go to separate pages, as needed, except for the manifest
-  We have no way of determining which of the reports will be the last report for that day, so we are not able to put an "end banner" on the last report.
-  I have tried adding a customer variable member that just adds a "top of page", but it doesn't work

Any help would be greatly appreciated.  I have tried the following Customer Variable combinations:
B=N  (WITH ANYTHING ON H= & T=) - System is not able to email the output
B=Y H=Y T=Y    -  Adds unwanted pages between the ReportIDs within the bundle (unacceptable), but forces manifest to a new page
B=Y H=N T=Y   - No unwanted extra pages between ReportIDs, but manifest starts at the bottom of the last ReportID
b=y H=Y T=N  - Adds unwanted pages between the ReportIDS within the bunde, and manifest prints at the bottom of the last ReportID
B=Y H=N T=N  - No unwanted extra pages between ReportIDs, but manifest starts at the bottom of the last ReportID


z/OS Server / Re: Contents of data in the CMOD.MIGR.BANNER.INPUT file
« on: January 14, 2018, 05:49:31 PM »
Thanks Nolan.  I am nose-deep in some other issues currently, but I will read the manual you supplied, and let you know if I come up with a solution that includes your challenge.

z/OS Server / Need page break on non-carriage-control character
« on: January 12, 2018, 01:34:23 PM »
We have some documents that I can't get to load correctly.  Here's is the info that impacts this:
-  They do NOT have carriage control, and we don't want carriage control added.
-  The "new page" should always start when it finds an X in column 1
-  Column 1 is used for data and must print as part of the data.
-  We use Indexer: OS/390
-  RECFM = Fixed
-  LRECL = 133
-  DATA TYPE is Line  (They're line data output from cobol programs)
-  I can't use the line count, because there could be a different number of lines from one page to the next.  NOTE: Although I can't use the linecount,  I tried that and found that it showed the correct number of pages within the view (if they were the same size), but it didn't show the correct number of pages in the page count in the list of results.

Do you know how to make this happen?  I have tried many combinations, using INDEXSTYLEs DOC and NODX.

Here is what I have coded currently, that doesn't break the pages based on the X.  NOTE:  The inpexit is one we have created.  If I don't include the input exit, it doesn't load at all.  If I use the "out-of-the-box" ARSEXINP, it abends ARSLOAD.

INPEXIT=CMDEXINP    /* This is an input exit that will add carriage control every 65 lines if it doesn't find it, if CC=YES */
CCTYPE=A   /*  This automatically gets added by the system if I don't code it */

Thanks Ed,
We still get that error, and I don't see any upgrades in our near future.  Thanks for the info!

z/OS Server / Re: Contents of data in the CMOD.MIGR.BANNER.INPUT file
« on: January 12, 2018, 06:39:30 AM »
I don't have a lot of info on that exit, so I haven't tried to change it/use it in any specific ways.  Can you expand on what I would need to do to make this happen?

z/OS Server / Re: ars.cfg parms for manifest
« on: November 09, 2017, 11:37:58 AM »
Hate to admit this a little, but I was misunderstanding the documentation.
Two areas I didn't understand:
   When I read that the new parm was created to allow bundles to be in separate spool files, or one, like manifest, I thought that meant there was a parm for manifest.
   When I saw the choices of manifest, no manifest, and manifest in sysout, I jumped to the conclusion that maninfest in sysout meant it would sit out in the sysout queue to view and not be printed.

So - solution is - just choose manifest in sysout.

I'm testing it tonight to see if that's enough to allow QDirect to keep it together, without changing the dynamic creation of the DD name for the output.

Just wanted to answer this to save somebody else the headache.

Here's the info from my ETS resource:
The ARS address spaces have 1.54G private area
, the OMVS segment for ARSSERVR already says ASSIZEMAX= 2147483647, which canít raise that 1.5 number but at least he can see it isnít lowering it.

Does that answer your questions/curiosity?


z/OS Server / ars.cfg parms for manifest
« on: November 08, 2017, 01:40:01 PM »
I've read manuals, programs, parms and copybooks and can't find the answer, so I'm hoping somebody can help here.
We recently started using manifests for several distributions.  The problem is that the manifest produces with a different DD name from the other output in the bundle, which causes issues when it is sent to our Print Product.
It looks like you can set a parm somewhere.  Can anybody tell me how to force the manifest to print with the same DD name(s) as the rest of the output for the bundles?
Currently, each piece of the bundle goes out to the spool with DD names that start with P, and the manifest goes out to the spool with a DD name that starts with M - I need the manifest to be "considered the next P.  (NOTE - It does keep all the output in the same spool job)
For example, I have a Distribution with 3 Report Bundles and a manifest.  It goes to the spool with the following DD names:
P0000001  (1st application)
P0000002  (2nd application)
P0000003  (3rd application)
M0000003 (manifest)

I need the manifest to go to the spool as part of the bundle, which would cause it to have the following DD names:
P0000001  (1st application)
P0000002  (2nd application)
P0000003  (3rd application)
P0000004 (manifest)

I set up the job to run, but it has to be run by our ETS department, I'll let you know about the results.

It's set to 30.  I can talk to our OAM Team to see if we can make it higher, if you think that will help.  That number came from our Health Check, but we've grown since then in our CMOD usage.

We randomly get the error ARS0131E ZCMOD01P No logical place to retrieve object  during distributions.  Normally, CMOD appears to correct itself and distribute correctly.  However, we recently had over 4000 of those errors during one nightly cycle, and the output was never distributed.
We researched and it appears that an incorrect, or empty, Storage Set is being set to OAM.  Since we have all of our Storage Sets correctly set up, we don't know what causes this.
Has anybody encountered and fixed this issue?
Is there a default "backup" storage set we should have set in one of our parms that we don't know about?

Any assistance would be greatly appreciated.


Pages: [1] 2 3