Re: SFTP Special Charcters
We use the Co:Z software from Dovetail on z/OS (as the client mostly) and perform EBCDIC to ASCII by default most of the time. There are cases where we have to specify the following at the client end to get things to land correctly on the ASCII server. lzopts mode=text,clientcp=ibm-037,servercp=utf-8 or lzopts mode=text,clientcp=IBM-037,servercp=ISO8859-1 see: https://dovetail.com/products/sftp.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink, searching SRs
Whoever in your organization handles User Administration for the IBM Support Site needs to verify that you have FULL (access to all cases in the the account number) as opposed to BASIC (you only see your own cases). If your company has multiple account numbers, that can complicate things. If software cases must be opened in specific account numbers, you and your peers would need FULL in all of those account numbers where you all work as a team. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 checkpoint location
Just an FYI - In a GDPS environment, I believe the recommendation is for all CKPTs to be on DASD. When a FREEZE event occurs, HASPACE and CKPTs will be in sync if both are on DASD. Updates to a CKPT in a CF may not be completely in sync with HASPACE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OpenSSH / Ported Tools / Co:Z
...phrase. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OpenSSH / Ported Tools / Co:Z
My apologies for the incorrect capitalization of the phase. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OpenSSH / Ported Tools / Co:Z
In a parallel sysplex with Shared File System implemented, has anyone toyed with the idea of having /etc/ssh on each system symlink to a common location ? I see a few pros but am wondering about any cons (especially bad ones) that this could encounter. Comments ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Health Check JES_NJE_SECURITY
Is is possible to add the profile (with possibly a dummy MEMBER subentry) as WARNING to the RACFVARS Class? Then monitor for the Temporary Access Allowed condition and use that information to build your ADDMEMs to the profile over time? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
There is not a put1801.txt so far ...
Have I missed something? There does not seem to be a put1801.txt file in the /s390/assigns directory on ftp://service.boulder.ibm.com so far. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Include FMID, PTFID and APARID as eye catcher in each LMOD
We clone the SMP/E Target Zone as well. Makes it easy to know what maintenance is on the IPL volume in question. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol and PreCompile for CICS and DB2
The last time I looked into doing that we had problems because certain scenarios were not supported using the integrated translator during the compile step. EXCI applications are what come to mind off the top of my head. Have all the restrictions been lifted at this point? If so, at what levels of COBOL and CICS T/S? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shopz Hung?
What ever it is, I think the same problem is also affecting SMP/E's RECEIVE service retrieval. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E: SMPWRKn and GLOBAL zone
In general, we add a DDDEF for SMPPARM to every SMP/E ZONE we utilize. That DDDEF points to a data set with our customized GIMDDALC member. Then we don't have to worry about SYSUTn, SMPWRKn, SMPTLIB, or any of the DDNAMEs that are used for SYSOUT(*). That way, if one of those DDDEFs is needed, it can be dynamically allocated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unix support of symbols in .profile
Kirk, My .profile is umask 027 Sys_MPT=$(sysvar SYSNAME) echo $Sys_MPT echo $HOME/$Sys_MPT/maxdate if [ ! -f $HOME/$Sys_MPT/maxdate ]; then /usr/sbin/mount -v -f UNIX.ZFS.QRDR.C2ECQRLF.$Sys_MPT ./$Sys_MPT echo "* The QRadar LEEF file was NOT mounted. *" echo "* A mount command has been issued. *" else echo "* The QRadar LEEF file was ALREADY mounted. *" fi The echo's in STDOUT are: SYSQ /u/c2ecqrlf/SYSQ/maxdate * The QRadar LEEF file was ALREADY mounted. * But STDERR is showing [: /u/c2ecqrlf/.profile 5: FSUM7351 not found and the mount was NOT performed. Something must not be right with my if statement. The if statement works when variables are not in the statement. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unix support of symbols in .profile
That was it! I normally run emulator A which is set up correctly as 1047. Pop'ed over to use emulator B (which is set up for 037) to assist a user having with a file transfer problem involved with some of those other special characters. Then I fell asleep at the wheel. Thanks for the reminder! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unix support of symbols in .profile
Thanks, Kirk! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Unix support of symbols in .profile
I'm stumped trying to use a system symbol in my .profile to perform a test for a file name. I'm coding along these lines: if [ ! -f //file_name ]; then echo "* The file is not there. *" else echo "* The file is there. *" fi Surely it's staring me right in the face! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RSU1509 PTFs showed up today
I usually have a RECEIVE RECOMMENDED run every couple of days for my z/OS GLOBAL zone. Today it pulled in 204 PTFs of which 202 were marked RSU1509. These PTFs had not previously shown up. The email from IBM with Subject: "New IBM z/OS RSU testing complete" came in back on Oct 7th. None of my RECEIVE processes since then had picked up any new RSU* assigned PTFs until today. I have never seen such a delay between getting the email and PTFs in the repository not getting updated. Anyone else seen this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 SPOOL question
Long running STCs that have allocated SPOOL on the mod-9 will be your problem. The $MSPL will not move active stuff. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMP/E ++HOLD COMMENT SYMP
To perform some reporting for PCI compliance, I would like to be able to be able to list out SYSMODs with ALL of the ++HOLDDATA that I have processed. We do load the SECINT assigns and holddata pulled from the security portal. However, once loaded, getting to the value that was in the SYMP parameter does not seem to ever be listed out except in a REPORT ERRSYSMODS format. I would like to be able to list out HOLDATA from the GLOBAL zone and then search for things such as 'SYMP(Bn'. I could use that to locate PTFs that have a higher Base CVSS score and then focus on higher priority vulnerabilities first. Anyone doing this or have any ideas other than just always installing all SECINT PTFs asap? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS segments created on demand
On Fri, 5 Jun 2015 12:09:42 -0500, John McKown john.archie.mck...@gmail.com wrote: I can, sort of, see a possible security concern here. At present, to access CICS, a RACF id must have a CICS segment. To access TSO, it must have a TSO segment. A CICS user cannot log in to TSO if they don't have a TSO segment. But, with the automatic UID GID assignment, that CICS user could, if they were knowledgeable enough, use PuTTY on their PC to connect and have a z/OS UNIX prompt. Depending on the environment, they may then have access to information to which they should not. Especially if the security department in the past has been lax because they can only get to stuff via CICS, so why bother with a lot of unnecessary data set profiles? At the very least, the unauthorized user could be running stuff for learning purposes which would use up CPU and DASD resources (e.g. fill up /tmp) and so impact performance and perhaps even billing (MSU increase). Can _you_ say fork bomb? Also, it could cause other problems with auditing. As in not having any reports for this sort of thing at present because nobody uses it. So now the auditors and security people may need to be involved. And that may have other, political, repercussions. John, Thanks for the additional input. You added some points that I was vaguely concerned about, but had not actually put words to in my haste to post what I consider to be a concern. Prior to the changes with the various BPX.*.USER profiles, I had not realized a user originally added to RACF for just CICS could acquire an session via ssh to the host. Therefore none of those userids have ever had OMVS(NOUID) added to them. I'm thinking that I might need to go alter all of those userids and our process for adding new userids to RACF needs to be changed. Anyone else out there already doing something in this area or have plans to do so? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: migrating compiler versions
We're going with VLR(STANDARD) also. Any problems encountered with FILE-STATUS 04 will be treated as something that needs to be investigated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECEIVE ORDER failing in the underlying FTP process
IBM is working to resolve the problem. They have updated the STATUS page at http://www14.software.ibm.com/webapp/set2/sas/f/gdbm/home.html to show the service is not available. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RECEIVE ORDER failing in the underlying FTP process
When attempting to pull current maintenance holddata today, the order was
built and then the ftp process started up to actually get the files from IBM to
my SMPNTS. But I encountered errors that I have not seen before. Anyone else
having problems?
The error reported in SMPOUT was
RECEIVE ORDER( ORDERSERVER (SMPEORDR) CLIENT (SMPECLNT)
FORTGTZONES (MVSTA21) /* == TARGET ZONE */
CONTENT( RECOMMENDED )
)
DELETEPKG .
GIM68700IORDER ORD00019 HAS BEEN SENT TO THE SERVER AT
https://eccgw01.boulder.ibm.com/services/projects/ecc/ws.
GIM69144IORDER ORD00019 IS READY FOR DOWNLOAD.
GIM45201S ** 553 /2014111359704/PROD/GIMPAF.XML: Permission denied. (dnload)
GIM46200IRECEIVE PROCESSING HAS FAILED BECAUSE THERE WAS AN FTP ERROR.
GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12.
Down in BPXPRINT I have:
Using 'DDS3.SEQ.TCPIP.FTP.DATA' for local site configuration parameters.
IBM FTP CS V2R1
FTP: EXIT has been set.
Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
220-IBM's internal systems must only be used for conducting IBM's
220-business or for purposes authorized by IBM management.
220-
220-Use is subject to audit at any time by IBM management.
220-
220 dhebpcb01 secure FTP server ready.
NAME (deliverycb-bld.dhe.ibm.com:MAGEE):
S1k15470
USER S1k15470
331 Password required for S1k15470.
PASSWORD:
PASS
230 Virtual user S1k15470 logged in.
Command:
BINARY
TYPE I
200 Type set to I.
Command:
GET /2014111359704/PROD/GIMPAF.XML
/x/smpe/smpnts/ORD00019-13Novembe
r2014-15.23.28/GIMPAF.XML (REPLACE
PORT 10,26,98,26,81,142
200 PORT command successful.
RETR /2014111359704/PROD/GIMPAF.XML
553 /2014111359704/PROD/GIMPAF.XML: Permission denied. (dnload)
Std Return Code = 16553, Error Code = 2
QUIT
221 Goodbye.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECEIVE ORDER failing in the underlying FTP process
It must be contagious. I just tried Rochester and encountered the same problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unix System Services file listings under ISPF vs ISHELL
I was leaving the implementation up to IBM. The current ISPF file listing is done using ISPF DM tables which does not provide any collating sequence options that the user can tweak. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Unix System Services file listings under ISPF vs ISHELL
I've gotten use to using ISHELL which displays the contents of a directory ignoring case sensitivity. ISPF can't do it that way ... you have to look through all the lower case names before getting to the upper case names. IBM ISPF recommended submitting an rfe in developerworks. Here is the link if you'd like to vote on it, etc. http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfeCR_ID=55767 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CSTRSU for RSU1312
Anyone have any info concerning RSU1312. The ++ASSIGNS finally showed up late last week but RECEIVE ORDER( ORDERSERVER ... jobs are not pulling anything with RSU1312. An email from IBM on the 10th stated: Hello, We are writing to notify our CST subscribers that RSU1312 will be available through ShopzSeries on Wednesday, January 15, 2014. Thank you for your continued interest in the RSU availability. z/Consolidated Service Test IBM Systems Technology Group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Standard TSO/MVS way to delete a PDS(E) member
If the PDS command package from cbttape.org (or Serena's Startool product) is used in batch, I think the ISPFEDIT ENQs are issued. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
