OS390 indexer

[DDP021]

Not sure where to post this question...Apologies if this isn't the correct forum...

Here is our issue...We collect NUMEROUS reports from the mainframe into OnDemand (version 8.5.06).  The jobs execute on the mainframe and then get collected into CMOD.  Most of the reports coming from the mainframe incorporate the OS390 indexer due to the fact that these are old mainframe based reports and the ACIF indexer wouldn't work.  The conversion to CMOD was primarily handled by IBM.  We are TRYING to determine how the out for these OS390 reports is getting from the mainframe to CMOD. Basically need to know, when the mainframe job runs and creates the output, where on the mainframe is it sent to, and then what CMOD process that is running "PULLS" that output off the mainframe and into CMOD.  We know the ACIF defined reports use the ARSLOAD process pointing to our ARSLOAD directories on the CMOD server.  But for the OS390 reports, its harder to determine...Below is a screen shot of a successful OS390 load (message 87). Anyone else using this type of process to collect mainframe data?

arsload: Processing file >/u/podep01/67307979 (DD:IN1-SYS17011.T000803.RA000.PODAJ7DR.RPTDSN.H03)<

arsload: 01/11/17 00:08:07 -- Loading started, --UNKNOWN-- bytes to process
OnDemand Load Id = >12869-14-0-285931FAA-17178-17178<
Loaded 1 rows into the database
Document compression type used - OD77.  Bytes Stored = >496< Rows = >1<
arsload: 01/11/17 00:08:08 Loading completed
arsload: Processing successful for file >/u/podep01/67307979 (DD:IN1-SYS17011.T000803.RA000.PODAJ7DR.RPTDSN.H03)<

[Greg Ira]

Can you give us a little more information such as what type of mainframe?
On our z/OS IBM Mainframe the output is dropped onto the JES spool where there is an ARSLOAD started task that monitors the spool and loads anything meeting the load definitions.  To me it sounds like this is what's happening with your output.

[DDP021]

Greg,  we are executing jobs on the mainframe that send out to CMOD for both ACIF and OS/390 indexed reports.   with the ACIF defined reports,  they can be seen coming across the "Virtual" Printers on the mainframe.  In our case, the mainframe "Printers" are defined as PRT8100-PRT8103.  After the mainframe jobs completes,  we can see the output going across these printers.  What determines what printer the jobs uses is defined in the mainframe JCL by specifying DEST=CMOD1 (for PRT8101), CMODBNYM2 (PRT8102) and CMOD3 (PRT8103).  We can also log into the production server (Via WINSCP) and look in the ARSLOAD1, ARSLOAD2 and ARSLOAD3 directories to monitor the ACIF collections.  We can also track ACIF loads from the SYSTEM LOAD directory on the desktop viewer software we have installed on our PC's.  What we are having problems with is identifying how the OS/390 process is configured on both the mainframe and server sides.  It doesn't appear to use anything what ACIF uses.   We are trying to determine , 1.) Where in the mainframe job it specifies where to send the output to on the mainframe side and 2.) What on the CMOD side triggers the data from the OS390 output to get pulled in to CMOD. Is it coming in via another port on the server?  We found the following on both the mainframe and server.  On the server side, its under the /usr/lpp/ars/config...Do OS390 loads also somehow use the ARSLOAD process?  What precipitated this is, we are going to be doing an upgrade and need to test all load scenarios in DEV environment and we have never loaded any mainframe jobs to DEV using OS/390.  We need to determine what needs to be changed to to allow that to happen
.
[@SRV@_DPYCSERR]
HOST=xsa00e70.example.com
PROTOCOL=2
PORT=0
SRVR_INSTANCE=DPYCSERR
SRVR_INSTANCE_OWNER=podep01
SRVR_OD_CFG=/usr/lpp/ars/config/ars.cfg
SRVR_DB_CFG=/usr/lpp/ars/config/ars.dbfs
SRVR_SM_CFG=/usr/lpp/ars/config/ars.cache

[@SRV@_DD]
PROTOCOL=1

[Greg Ira]

OS390 does use ARSLOAD as well.  Same as ACIF.

[Justin Derrick]

This thread was lightly edited to remove identifying information. 

-JD.

[ewirtz]

Hi,

it would help to see the JCL of your ARSLOAD instances.

regards

Egon

[DDP021]

Thanks Justin for the catch and removal!!!.....

[DDP021]

Thanks Greg...We did see a reference to ARSLOAD in the 87 message for our OS/390 Loads..As indicated, they (OS390) don't use the same "Virtual" printer instances defined on the mainframe like the ACIF loads do.  Also don't see them coming in the any of the ARSLOAD* folders on the server (like ACIF).  We need to determine how when the job runs where the output is sent to on the mainframe and from there, how its sent to our CMOD server.  If ARSLOAD is being used, is it on the mainframe or server side?  And where in the ARSLOAD definition is it determined where to send the data to (ie CMOD)? We have JCL for loading OS390 reports to PROD. In looking at the PROC  we see this line, //ARSBIN   DD PATH='/usr/lpp/ars/V8R4M1/bin'.  we found a similar path on the CMOD server /usr/lpp/ars/config/ars.ini which shows the host name of our server. Our problem is, when we converted to CMOD years ago, IBM set all this up. And the people who worked on the conversion are long gone. ;-)...
[@SRV@_DPYCSERR]
HOST=xxxxxxxxxxxxxxx
PROTOCOL=2
PORT=0
SRVR_INSTANCE=DPYCSERR
SRVR_INSTANCE_OWNER=podep01
SRVR_OD_CFG=/usr/lpp/ars/config/ars.cfg
SRVR_DB_CFG=/usr/lpp/ars/config/ars.dbfs
SRVR_SM_CFG=/usr/lpp/ars/config/ars.cache

[@SRV@_DD]
PROTOCOL=1

[Greg Ira]

We have JCL for loading OS390 reports to PROD.

Can you post that JCL?  That would help

[DDP021]

here ya go..Hope this helps!...thanks again for all the help and time!!!

[Greg Ira]

That helps a lot.
Based on this job you are basically loading from a dataset instead of a directory.

In step ODA30S20 you are taking the input dataset and sorting it into a temporary dataset "&&RPTDSN"
Step ODA30S25 is running ARSLOAD using the temp dataset created in step above as the input dataset:  "-s IN1"
 (You see IN1   DD DSN=&&RPTDSN in JCL later)

This gets loaded to your server DPYCSERR ("-h &H"  which points to H=DPYCSERR earlier in the proc)
And to the application defined in the calling job RPTID=GSP36201  (-a &RPTID)

Does this clear it up any for you?

[DDP021]

Yes it does...The only question remaining is, IF/WHEN there are changes to say the CMOD server name, where are changed needed, if anywhere?  I have to do some checking around to determine what the DPYCSERR is also....The main goal is to determine what changes, if any, need to be done on either the mainframe or CMOD server side, if any, if there are changes made to either the IP address or DNS name for the CMOD server itself....


Also, right now we have the ability to load data to our DEV server (XSA00Z96) ...Prod is XSA00E70 but we were never  given any JCL or documentation on how to load OS390 to our DEV environment. 

Can't thank you enough for all the help!!!!!

[Greg Ira]

If the server name changes you will need to make a change to the PODA30SR PROC or any other similar PROC that is used to load documents by modifying the H=cccccccc parm in the proc.
If you are upgrading you will/should likely change the CMOD= parm to point to the new loadlib HLQ (eg SYS1.ONDEMAND.V95)
In the proc you will also need to change the path of the ARSBIN to match the new install path.

You will also need to change ars.ini if the IP address, host name, or server name changes.

[DDP021]

I was just typing when I saw your replied back also...lol..I found out that the DPYCSERR is the name of the DB2 database running on the CMOD production server....Our mainframe guy found the attached directory on the mainframe side...I also found a similar file defined on the CMOD production server under the /usr/lppp/ars/config/ars.ini directory. Below is as screen shot. As you can see, both have a HOST name defined (Current production DNS name for PROD CMOD server)..My thinking is, if there is a change to this name,  both these directories will need to be changed..Is that what you are thinking also?

[@SRV@_DPYCSERR]
HOST=xsa00e70.bankofny.com
PROTOCOL=2
PORT=0
SRVR_INSTANCE=DPYCSERR
SRVR_INSTANCE_OWNER=podep01
SRVR_OD_CFG=/usr/lpp/ars/config/ars.cfg
SRVR_DB_CFG=/usr/lpp/ars/config/ars.dbfs
SRVR_SM_CFG=/usr/lpp/ars/config/ars.cache

[@SRV@_DD]
PROTOCOL=1

[DDP021]

forgot to attach mainframe directory screen shot...apologies