OnDemand User Group
Support Forums => z/OS Server => Topic started by: Ed_Arnold on May 02, 2018, 06:34:53 AM
-
IF you're running ODF
AND
IF you use email distributions to email addresses
AND
IF you're using SMTP on z/OS to distribute those emails
THEN
you can't do that anymore because the SMTP client (now called CSSMTP) no longer accepts input from port 25 (or any port for that matter)
Ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halz002/cssmtp_differences_with_smtpd.htm (https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halz002/cssmtp_differences_with_smtpd.htm)
If you are currently using Communications Server SMTPD on z/OS®, you should migrate to CSSMTP. IBM® has issued a statement of direction indicating that SMTPD will be withdrawn in a future release. CSSMTP has been designed to support z/OS users of SMTPD that create mail on the JES spool data set using batch jobs or that use SMTPNOTE for delivery to the Internet.
Note that this says create mail on the JES spool ... nothing about connecting via port 25 like we used to
CSSMTP does not perform DNS lookups to determine a target server for each recipient. CSSMTP requires a connection to an SMTP or ESMTP server that receives the mail and handles next-hop delivery. Typically, the target server is located at a remote destination, but could also be a local instance of sendmail.
Bottom line is you'll have to point SRVR_ODF_CFG away from z/OS (or to an older z/OS).
Ed
-
Well that's an alarming development. We currently do a lot of ODF distribution through SMTP and we're at V2.2. V2.3 is set to be done next year. Joy.
-
What I'm now doing is pointing ODF to a Linux box that's our SMTP server.
Ed
-
Mind if I pick your brain on this?
How does that work? You mention changing SRVR_ODF_CFG to point to something else, in your case the Linux box. Does that mean you have a full ODF installation on that box?
-
Does that mean you have a full ODF installation on that box?
Not at all.
I don't know what else may be on that box but I know it has an SMTP mail server set up, just like on z/OS V2.2 and below.
It's just magic
Here's the line in my ars.ini which points to the ODF config file:
SRVR_ODF_CFG=/etc/ars/V950/arsodf.dcerptmail.xml
Then I changed this line in arsodf.dcerptmail.xml:
<!--
- These settings are used for all email notifications.
-->
<SMTPServer>bluemail.raleigh.ibm.com</SMTPServer>
<SMTPServerPort>25</SMTPServerPort>
<SSL>false</SSL>
Linux server bluemail.raleigh.ibm.com is already behind the firewall and I didn't have to do a thing.
Just point to it and TCP/IP handled everything else.
Ed
-
Simple JCL to test connectivity to the SMTP server:
// JOB
//TMP1 EXEC PGM=IKJEFT01,
// DYNAMNBR=200
//SYSPROC DD DSN=SYS1.SBPXEXEC,DISP=SHR
//*
//SYSTSPRT DD SYSOUT=*
//*
//SYSTSIN DD *
oshell echo 'Sent from Ed Arnold on the MVS222.' | +
/usr/lpp/tcpip/bin/ezatmail -v earnold1@example.com
/*
You can run this right now, it places a file on spool for the SMTP server to pick up and send.
Note: this does not use port 25
CSSMTP on z/OS V2.3 is a CLIENT, not full-function SMTP.
When our support people configured CSSMTP on V2.3 they pointed CSSMTP to bluemail.raleigh.ibm.com.
The JCL above, as before, places a file on spool, then CSSMTP picks it up and forwards it on to bluemail.raleigh.ibm.com for delivery.
Repeating, you can't connect to CSSMTP via port 25.
Ed
-
Before migrating to z/OS V2.3 have OA54019/UA93819 APPLYed.
Symptom is ARS0430E ... OAM Error: ARSMVSDW: 0000000a(0001000d)
Ed
-
Tuning the JES2 Checkpoint is always a concern.
Starting in z/OS V2.2 you can have JES2 automatically choose optimal values.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.hasa300/has2v5_automatic_approach.htm
Ed
-
OA55725
ERROR DESCRIPTION:
zLib deflate() call returns Z_STREAM_ERROR (RC=-2) with a
z_stream *msg = System Error 003. This is a translated message
that is generated from a RC = x'C' RSN = x'XXXX0206' from
FPZ4ABC, compression driver. This return code / reason code
combination indicates that the generated compression output is
larger than the internal zEDC buffer.
-
Hi Ed, I'm a little confused about ODF and email. You mentioned the parameter SRVR_ODF_CFG . We don't have that parameter and the knowledge center indicates that this is a parameter for IBMi , not z/OS.
Could you please clarify?
Thanks.
-
Hi Ed, ...You mentioned the parameter SRVR_ODF_CFG . We don't have that parameter and the knowledge center indicates that this is a parameter for IBMi , not z/OS.
Could you please clarify?
Thanks.
Well, I thought I was going to google and point you right to the doc. Wrong!
Okay, that's something for me to follow up on.
Anyway, on my 9.5 system I've always had in ars.ini (not in the config) a line:
SRVR_ODF_CFG=/etc/ars/V950/arsodf.xml
That file is in ASCII. (Ugh)
To work with it I do a 3.17
17 Udlist Print or display (to process) z/OS UNIX directory list
which takes me to a panel
z/OS UNIX Directory List Utility
Type in /etc/ars/V950 and I get a list of all of the members.
In front of arsodf.xml I type in EU for Edit a UTF-8 file
I can now work with that file.
Inside there is this:
<!--
- These settings are used for all email notifications.
-->
<SMTPServer>linuxbox.example.com</SMTPServer>
<SMTPServerPort>25</SMTPServerPort>
<SSL>false</SSL>
That tells ODF where to send emails for distribution.
Ed
-
On our z/OS v9.5 system we find the SRVR_ODF_CFG parameter in ARS.INI
Ý@SRV@_OND14T¨
HOST=##.##.##>##
PROTOCOL=2
PORT=1446
SRVR_INSTANCE=OND14T
SRVR_INSTANCE_OWNER=OND14T
SRVR_OD_CFG=/etc/ond/ars14t.cfg
SRVR_SM_CFG=/etc/ond/14T/ars.cache
SRVR_OD_STASH=/etc/ond/ars14t.stash
SRVR_ODF_CFG=/etc/ond/arsodf14t.xml
Ý@SRV@_OND14P¨
-
Well, we don't have that. We have a file arsodf.xml under config. It has the SMTPServer tag pointing to our mail server (outside the mainframe) and no SMTPServerPort. I think we'll be OK.
-
Interesting.
1) I think 25 is the universal default port for for plain old non-encrypted SMTP.
2) So what's the line you have in your ars.cfg that points to arsodf.xml? I'm curious.
Ed
-
There is no parameter. According to the 9.5 manual "The ARSODF.XML file is located in the config directory on your Content Manager OnDemand server.". So, that's what I did when I installed CMOD 9.5 in 2015. Just customized ARSODF.XML and placed it under/config.
-
Looks like you're picking up a default.
Ed
-
More recommended maintenance:
After applying z/OS maintenance I can no longer retrieve OnDemand V2 migrated documents.
http://www-01.ibm.com/support/docview.wss?uid=swg22008017 (http://www-01.ibm.com/support/docview.wss?uid=swg22008017)
Ed
-
LE APAR PI93384
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
* Users of POSIX(ON) Language Environment *
* applications which expect to roll back the *
* in-progress update to the recoverable *
* resources when SIGXCPU is received and *
* there are no signal handlers registered for *
* SIGXCPU by the applications. *
****************************************************************
* PROBLEM DESCRIPTION: *
* When Language Environment applications *
* are terminated with return code 3000 *
* due to unhandled SIGXCPU under *
* POSIX(ON), the in-progress updates to *
* recoverable resources would be *
* committed instead of being rolled back. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
See the problem description.
PROBLEM CONCLUSION:
The code has been changed to ensure that, when a Language
Environment application is terminated with return code 3000 due
to unhandled SIGXCPU under POSIX(ON), the ThliAbnormalTerm flag
for all the threads in the process which receives SIGXCPU are
set to ON to notify Unix System Service to propagate the flag
to TCB_PTHREADTERMABNORMAL. The TCB_PTHREADTERMABNORMAL flags
are set to ON to indicate that the TCBs are terminated
abnormally. Then DB2 or other resource managers can check the
TCB_PTHREADTERMABNORMAL flags to determine commit or roll back
the in-progress transactions.
TEMPORARY FIX:
*********
* HIPER *
*********
In other words
OLD BEHAVIOR - the in-progress updates to recoverable resources would be committed instead of being rolled back.
NEW BEHAVIOR - DB2 or other resource managers can check the TCB_PTHREADTERMABNORMAL flags to determine commit or roll back the in-progress transactions. Which in the case of CMOD because there are no signal handlers registered for SIGXCPU by the applications means that things uncommitted get rolled back.
Ed
-
Do you have OAM toleration APAR OA51129 already installed on your z/OS V2.1 or V2.2 system?
If so, then you're all set and the rest of this doesn't apply to you.
If, however, you're upgrading to V2.3 and haven't put on the following toleration APAR yet then this applies:
1) APAR OA51129 has the following warning message:
"**Warning** Information APAR II14842 should be reviewed before
applying OA51129. If II14842 precautions are not observed then
there may be a potential loss of object addressability."
http://www-01.ibm.com/support/docview.wss?uid=isg1OA51129
2) Technote to alert customers about the possible effects:
OAM Object Required Considerations prior to installing OA51129 or
upgrading to z/OS 2.3
https://www-01.ibm.com/support/docview.wss?uid=ibm10728703
3) AI that was included in PTF UA91367
"Prior to coexistence APAR OA51129, OAM s object support would
maintain collection information in two places; in DB2 (in the
OAM collection table) and also in the catalog. With new function
introduced in z/OS V2R3 (support for multiple OAM instances to
exist on the same LPAR) and requirements around that support,
OAM is now only going to maintain this collection information in
DB2 (regardless of whether the new support is being used). For
most customers, the information that was in the catalog and in
DB2 should be in synch; however, there is no absolute guarantee
that this is the case. As we have discovered, the most likely
cause for an out-of-synch condition is the customer themselves
needing to clean-up and/or rebuild their collection environment.
To be as proactive as possible information APAR II14842 was
created along with a REXX comparison tool for customers to run.
This tool compares the OAM collection information in the catalog
and in DB2 and surfaces any inconsistencies that it detects. If
the tool is not run, this out-of-synch condition could exist for
years, until the customer goes and retrieves an object from that
particular collection."
4) Informational APAR II14842 with the CATDB2CP tool
http://www-01.ibm.com/support/docview.wss?uid=isg1II14842
-
Abstract:
EXCEPTION S0C4 IN IGZXPRS1 OFFSET X'3E2'
ERROR DESCRIPTION:
s0c4 exception in IGZXPRS1 due to an invalid GBCP address.
Failing instruction is an OI (9601 E004). The failing program
is compiled with THREAD, DLL, EXPORTALL, and
PGMNAME(LONGMIXED), and when program is linked on z/OS 2.3.
LOCAL FIX:
Link on z/OS 2.1 or 2.2
PI98700
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: Users of Enterprise COBOL V5 and later *
* releases, running COBOL programs compiled *
* with the DLL option. *
****************************************************************
* PROBLEM DESCRIPTION: Runtime ABEND S0C4 in IGZXPRS1. *
****************************************************************
* RECOMMENDATION: Apply the provided PTF. *
****************************************************************
When an Enterprise COBOL V5+ program compiled with the DLL
option is loaded and entered without LE knowing, for example
with SVC LOAD and BASR, or when the DLL program is used as a
Content Manager OnDemand user exit, the program WORKING-STORAGE
may not be initialized properly, resulting in a S0C4 ABEND in
COBOL runtime module IGZXPRS1.
-
CMOD has exposed the following:
OA57775: FILE READ/WRITE FAILURES. OPEN FILE WITH O_APPEND RWSHARE
Opening files with O_APPEND for IO operations can have
unexpected results in an RWSHARE environment sysplex
where concurrent access from multiple systems to the same
file(s) is occurring.
Symptoms vary, depending upon the application but some symptoms
are lseek errors
Ex.
-EDC5137I Inappropriate I/O control operation
- Incorrect offsets returned
- file corruption
This issue was encountered when the CMOD zFS cache was converted to RWSHARE in a very high volume environment.
Ed
-
If you're migrating from z/OS V2.2 or below, make sure you use the current CBRIBIND member from SYS1.SAMPLIB:
...
//* $P2=OAMR23M R23 161013 TUCAED: Missing prolog multi reference
//* $P3=138323 R23 161101 TUCAED: Added CBRIDBSV package and
//* updated prolog
...
Ed
-
CMOD exposes the following z/OS issue:
Symptom: long running ARSYSPIN task hangs.
Cause: Virtual storage shortage
Fix: OA58421: PRLRMAIN & DAGSH WORK AREA NOT BEING FREED AFTER ABEND IN DADSM PARTIAL RELEASE
Ed
-
CMOD exposes the following z/OS issue:
Symptom: long running ARSYSPIN task hangs.
Cause: Virtual storage shortage
Fix: OA58421: PRLRMAIN & DAGSH WORK AREA NOT BEING FREED AFTER ABEND IN DADSM PARTIAL RELEASE
Ed
Hit this again --- not so long running but fairly active ARSYSPIN started task took an 878.
https://www.ibm.com/support/pages/apar/OA58421 (https://www.ibm.com/support/pages/apar/OA58421)
Ed
-
You can display reason code information for the OAM and OSREQ macros directly from a console or a TSO session, as of APAR OA58344 for V2R3 or later. These commands can also be invoked via JCL to aid in automation of error information capturing in real time.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idao200/displayoaddr.htm (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idao200/displayoaddr.htm)
Ed
-
There was a problem with mixed case passphrases during MFA Web authentication where MFA incorrectly folded a passphrase to uppercase, and is fixed in MFA 2.0 and MFA 1.3 with PTF UI66464.
-
CMOD exposes the following JES2 issue:
OA60092: STORAGE ABENDS IN INITIATOR FOR SSI FUNCTIONS
VERIFICATION STEPS:
1) z/OS 2.2 and later, HJE77A0, HJE77B0, HJE77C0
2) Storage abends for jobs in Initiator
-
OA62618: CBR9912I RSN9013 DURING OSMC OR OSREQ RETRIEVE REASON CODE X'80030200'
Error description
• The issue may be surfaced in either of the following ways: 1)
• During OSMC processing: CBR9912I groupxx CBRHRDAS A request to
• read Object from collection collection-name,object object-name
• in groupxx failed. The return code is 16, and the reason code
• is 9013. 2) Failure from an application to OSREQ RETRIEVE an
• affected object. The OSREQ REASON CODE returned to the
• application is x'80030200'. This issue occurs for a subset of
• object sizes if BUFFER64 was used on the OSREQ STORE that stored
• the object and the object was stored to the LOB table.
•
• IDENTIFICATION:
• The following SPUFI may be run against each Object Storage Group
• that utilizes LOB tables to identify objects affected by this
• issue:
•
• SELECT 'GROUPxx', ODNAME, ODCLID, ODLOBFL, ODSIZE, LENGTH(OTOBJ)
• AS LENGTH
• FROM hlq.OSM_OBJ_DIR
• LEFT JOIN hlq.OSM_LOB_BASE_TBL
• ON OTNAME = ODNAME
• WHERE LENGTH(OTOBJ) <> ODSIZE;
•
• *where hlq is the DB2 qualifier of the Object Storage Group
• table being investigated
•
• If the ODSIZE is 1 byte greater than the length of OTOBJ and is
• a multiple of (1048568 x n) +1, then the object is affected by
• this issue.
•
• ADDITIONAL SYMPTOMS:
• CBR9912I OSREQ ODSIZE
Contact OAM support for details and fix.