Hi,
I have a problem i can't understand. Sometimes (not often) an application (several applications have the same problem) is ok to load a file into CMOD and sometimes it's necessary to submit 2 times the same JCL because the first has stopped with ABEND SA03 after indexing before the load. If i submit the same JCL without change nothing the load is ok! Is anybody knows what happens? I have joined 2 joblogs, for the same application, in this topic: First load is ok with 1 submit, second load ok with an other submit after ABEND SA03.
Thanks for your help
Best regards
Philippe
Bonjour Philippe!
You can get an SA03 abend from an ARSLOAD for various reasons ...
a) ARSLOAD has previously connected to ARSSOCKD and then attempts to
store a document after ARSSOCKD has ended/abended/stopped.
b) ARSSOCKD was stopped while ARSLOAD was running as a STC
processing spool files.
c) ARSLOAD attempts to initialize without ARSSOCKD. ARSLOAD
requires ARSSOCKD be active.
d) network communication between arssockd and arsload is not
available when arsload needs it
e) when DB2 becomes unavailable. OnDemand has no real toleration of
a lost DB2 connection.
f) if you run out of file handles. You can check for this with the
following process ...
/D OMVS,A=ALL
to get the PID of ARSLOAD and then issue:
/D OMVS,L,PID=<arsload pid value from above>
The ARSLOAD STC should not have a MAXFILEPROC high water usage at
or near the process limit.
Could any of the above occurred?
Hi Ed,
Thanks for your reply. I understand my problem now. At the moment we have a problem with several writer started for CMOD. The job ARSMAINP doesn't work correctly, the writer hasn't stop but started again. Yesterday we had 4 writers, perhaps it's an explanation for ABEND SA03?
Thanks for your cooperation and your help
Best regards
Philippe
Philippe - a lot of things can cause an A03 abend....but the bottom line pretty much always is that "somebody is not talking to somebody else" --- whether it's something not being started, or performance causing a delay, or some other reason.
Hi Ed,
I just have the reply of system team about your question, here:
D OMVS,L,PID=590404
BPXO051I 14.22.40 DISPLAY OMVS 835
OMVS 000F ACTIVE OMVS=(AF,XV,TJ)
USER JOBNAME ASID PID PPID STATE START CT_SECS
ARSWRITP ARSWRITP 003F 590404 1 1RI--- 10.12.30 54.177
LATCHWAITPID= 0 CMD=ARSLOAD
PROCESS LIMITS: LIMMSG=NONE
CURRENT HIGHWATER PROCESS
USAGE USAGE LIMIT
MAXFILEPROC 2 10 65535
MAXFILESIZE --- --- NOLIMIT
MAXPROCUSER 19 29 2000
MAXQUEUEDSIGS 0 0 1000
MAXTHREADS 0 1 10000
MAXTHREADTASKS 0 1 5000
IPCSHMNSEGS 0 0 100
MAXCORESIZE --- --- 2147483647
MAXMEMLIMIT 0 0 16383P
It's ok for us about your interrogations, how can we resolve our problem?
Because it's a very big problem in our department, i had have 4 load today to submit the jcl again to have the successfull load.
Thanks for your help
Best regards
Philippe
Philippe - with those kinds of numbers you're not running out of file handles.
You're on V7 of CMOD? Do you have PTF UQ85534 installed? This is an old PTF, but it has never been SUPed.
ADD NO TCPIP ARSLOAD, ADD ABILITY TO DISABLE ARSLOG PROCESSING,
ELIMINATE DUPLICATE LOGOFF MESSAGES. QuotePROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: All with OnDemand for z/OS V7R1M0. *
****************************************************************
* PROBLEM DESCRIPTION: Currently, ARSLOAD/ARSADMIN uses TCP/IP *
* to communicate with the server. This *
* APAR provides a means for *
* ARSLOAD/ARSADMIN to perform the server *
* functions directly. That is, it will *
* directly interact with DB2 and VSAM/OAM *
* instead of routing requests to the *
* server. *
* *
* The ARSLOG exit can get invoked for *
* messages even though the System *
* Parameters window of the Administrative *
* Client does not have anything checked *
* for User Exit Logging. This is by *
* design. In order to allow an *
* installation that is not using the *
* ARSLOG exit to indicate that no *
* attempt is to be made to call ARSLOG, *
* a new ars.cfg entry is provided to *
* disable this. *
* *
* For a given load, the logoff message *
* (message number 32) can appear twice *
* in the OnDemand system log. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
Currently, ARSLOAD/ARSADMIN uses TCP/IP to communicate with the
server. This APAR provides a means for ARSLOAD/ARSADMIN to
perform the server functions directly. That is, it will
directly interact with DB2 and VSAM/OAM instead of routing
requests to the server.
The ARSLOG exit can get invoked for messages even though the
System Parameters window of the Administrative client does not
have anything checked for User Exit Logging. This is by design.
In order to allow an installation that is not using the ARSLOG
exit to indicate that no attempt is to be made to call ARSLOG,
a new ars.cfg entry is provided to disable this.
A flag was not getting set to indicate that a logoff message
should not be put in the OnDemand System log.
Are you using NOTCPIP (direct writes) ? It might help.
To properly set up to do direct writes to DB2 you need:
- ARSLOAD and ARSSOCKD are running under the same RACF or ACF2 userid.
- ARSLOAD and ARSSOCKD are running on the same system.
- The -h parameter specifies the instance name (ARCHIVE) of the server
in the ars.ini file and not a host name.
- DSNAOINI DD is present.
- ARSMVS_ARSADMIN_USETCPIP=0 in ars.cfg