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)<
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.
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
OS390 does use ARSLOAD as well. Same as ACIF.
This thread was lightly edited to remove identifying information. :)
-JD.
Hi,
it would help to see the JCL of your ARSLOAD instances.
regards
Egon
Thanks Justin for the catch and removal!!!..... :D
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
QuoteWe have JCL for loading OS390 reports to PROD.
Can you post that JCL? That would help
here ya go..Hope this helps!...thanks again for all the help and time!!!
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?
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!!!!!
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.
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
forgot to attach mainframe directory screen shot...apologies
Correct. If host, install directories, and other information changes you will need to modify those ars.ini files.
Just to reiterate. The name resolved by the -h parm in your proc should match the name specified in the @SRV@ line of the ars.ini on the mainframe. You have a lot of version names in your paths as well. Make sure you note which, if any, of those change when you upgrade and modify those paths accordingly in all your config files and JCL.
Thanks Greg..From what I'm being told, the DB2 database name will not be changed when the upgrade occurs...We are told the HOST name though will be changing from XSA00E70. So when that does occur, our engineers on the CMOD side will need to do their change as well as the mainframe guys side....As I indicated, my group are just the ADMINS for CMOD...We do new setup for Applications as well as any changes to APPLICATION GROUPS, APPLICATONS and FOLDERS...Also defined users and accesses...I'm just trying to do some digging so I can pass the information on to the needed groups...There sometimes is a conflict with mainframe and distributed folks as far as one saying its on the others side...haha...I can't thank you enough for all your valuable input!...Learned a whole lot today on how this whole OS390 process works just from going back and forth with you!!!!
Take care!
Dave