Re: z14 and zBX

[R.S.]

W dniu 2017-08-27 o 17:34, Ed Jaffe pisze:

On 8/22/2017 4:27 AM, R.S. wrote:


The above is some simplification, however I heard A LOT OF zBX, saw a 
lot of presentations, and  IBMers never ever convinced me the zBX is 
something more than LAN-attached rack.


zBX was a mistake. Every company makes them.


My English is poor, do you mean every company makes zBX or every company 
makes errors?  ;-)))


--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[Clark Morris]

[Default] On 27 Aug 2017 16:54:26 -0700, in bit.listserv.ibm-main
idfli...@gmail.com (scott Ford) wrote:

>David, All,
>
>I have to think about hardening a COBOL written STC performing security
>calls. This my main reason for the question regarding the I/O error
>handler, it makes sense to move the I/O into an assembler module or C..
>
If you want the program to control the I/O error handling, adding a
status code to the FD (the name of a 2 character PIC XX field normally
in WORKING-STORAGE) and checking it after ALL I/O operations to take
appropriate action should be adequate.

Clark Morris
>
>Scott
>
>
>On Fri, Aug 25, 2017 at 12:07 AM David Crayford  wrote:
>
>> On 25/08/2017 11:10 AM, Farley, Peter x23353 wrote:
>> > That may well be true, but use of C stdio then requires POSIX mode,
>> which makes it not suitable for a *generalized* file handler which might,
>> for instance, need to be invoked in a totally non-LE environment.
>>
>> Good point about the non-LE environment.  The only time I run non-LE
>> these days is systems level programming and I don't do much of that. I'm
>> doing a lot of Java work these days and C stdio pops it's head up again
>> when using ZFile. It's remarkable that I only need one simple wrapper
>> class to access all the different file types on z/OS. It's not perfect
>> though. I wish it had better support for enumerating PDS members.
>>
>> There is no POSIX requirement for C stdio (or sockets). In my experience
>> the only time I've required POSIX semantics is to use runtime functions
>> for threads, mutexes and IPC stuff.
>>
>> > I would agree with "hundreds of lines" but not thousands.  QSAM support
>> only takes a few hundred, even including MOVE/LOCATE and UPDATE modes (and
>> a lot of that can be explanatory comments for the next maintainer).  Maybe
>> by the time the BSAM/BDAM/VSAM support was done you would have a thousand
>> or more lines, but not I think two or three thousand.
>> >
>> > Depending on how many bells and whistles you want to include of course.
>> As usual, YMMV.
>>
>> We've got a common code assembler VSAM I/O program that's ~1700 LOC, but
>> it does have quite a few bells and whistles. fopen() has extra bling
>> like dynamic allocation. Our assembler dynalloc routine is 987 LOC.  It
>> all adds up and that's before adding extra layers of abstraction.
>>
>> >
>> > Peter
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of David Crayford
>> > Sent: Wednesday, August 23, 2017 12:53 AM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: Cobol Help
>> >
>> > On 22/08/2017 11:59 PM, Farley, Peter x23353 wrote:
>> >> In that case the assembler I/O modules handled any errors that they
>> could (SYNAD, etc.) and passed back error code(s) and messages to the COBOL
>> interface module to pass up to the caller, simulating COBOL FILE STATUS and
>> VSAM error variable where possible.
>> >>
>> >> Metal C might be a better choice for more generalized file I/O
>> handling, one small step above assembler but with all assembler facilities
>> available.
>> > The best generalized file handling I've seen on z/OS is the C stdio
>> > fopen() and friends (by a country mile). That one factory function can
>> handle all the standard access methods: BSAM, QSAM, VSAM (KSDS, RRDS,
>> ESDS), hiperspaces and Unix files. It's a thing of beauty. To code the
>> equivalent functionality in Metal/C would take hundreds if not thousands of
>> lines of code.
>> >
>> > --
>> >
>> >
>> > This message and any attachments are intended only for the use of the
>> addressee and may contain information that is privileged and confidential.
>> If the reader of the message is not the intended recipient or an authorized
>> representative of the intended recipient, you are hereby notified that any
>> dissemination of this communication is strictly prohibited. If you have
>> received this communication in error, please notify us immediately by
>> e-mail and delete the message and any attachments from your system.
>> >
>> >
>> > --
>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Steve Smith]

I can only guess that this particular register dump comes from a
32-bit savearea.  Deliberately masking off the high-halves when
available would be profoundly asinine.  Say it ain't so, LE!

sas

On Sun, Aug 27, 2017 at 5:01 PM, Charles Mills  wrote:
...
>
> LE fails to print the high register halves, for example
>
> GPR0. _00C6  GPR1. _0020  GPR2. 
> _  GPR3. _0002
>
> If I had nothing better to do I would open an RFE on that. Even assuming 
> AMODE 31, how can LE assume that the high halves of the registers are of no 
> debugging value? 64-bit register arithmetic -- or even using the high halves 
> of registers as a temporary holding area -- is a valid technique even in the 
> absence of AMODE 64. The C/C++ compiler itself does so.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

I can see all 64 bits in the SDWA.
CharlesSent from a mobile; please excuse the brevity.
 Original message From: Steve Smith  Date: 
8/28/17  8:47 AM  (GMT-05:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Can 
AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler? 
I can only guess that this particular register dump comes from a
32-bit savearea.  Deliberately masking off the high-halves when
available would be profoundly asinine.  Say it ain't so, LE!

sas

On Sun, Aug 27, 2017 at 5:01 PM, Charles Mills  wrote:
...
>
> LE fails to print the high register halves, for example
>
> GPR0. _00C6  GPR1. _0020  GPR2. 
> _  GPR3. _0002
>
> If I had nothing better to do I would open an RFE on that. Even assuming 
> AMODE 31, how can LE assume that the high halves of the registers are of no 
> debugging value? 64-bit register arithmetic -- or even using the high halves 
> of registers as a temporary holding area -- is a valid technique even in the 
> absence of AMODE 64. The C/C++ compiler itself does so.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[bernd.oppol...@t-online.de]

it was 2005 ca., when we decided at my Former customer's Site to replace 
the four or five different Abend Handling and dump printing Routines by 
one. The Input was different, the Output should be the Same. only one of 
the Input Variants then Had 32 Bit Registers, all others were alresdy 64. 
Of course, we Always showed 64 Bit register contents, when possible.



Gesendet mit der Telekom Mail App




--- Original-Nachricht ---
Von: Charles Mills
Betreff: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 
assembler?
Datum: 28.08.2017, 15:15 Uhr
An: IBM-MAIN@LISTSERV.UA.EDU





I can see all 64 bits in the SDWA.
CharlesSent from a mobile; please excuse the brevity.
 Original message From: Steve Smith  
Date: 8/28/17 8:47 AM (GMT-05:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 
Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
I can only guess that this particular register dump comes from a
32-bit savearea.  Deliberately masking off the high-halves when
available would be profoundly asinine.  Say it ain't so, LE!

sas

On Sun, Aug 27, 2017 at 5:01 PM, Charles Mills 
> ; wrote:
...
>
> LE fails to print the high register halves, for example
>
> GPR0. _00C6  GPR1. _0020  GPR2. 
_  GPR3. _0002
>
> If I had nothing better to do I would open an RFE on that. Even assuming 
AMODE 31, how can LE assume that the high halves of the registers are of no 
debugging value? 64-bit register arithmetic -- or even using the high 
halves of registers as a temporary holding area -- is a valid technique 
even in the absence of AMODE 64. The C/C++ compiler itself does so.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu  with the 
message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu  with the 
message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Create subtask w/out a load module?

[Steve Smith]

I've got cases where the module is copied into CSA (w/o benefit of
DYNLPA, and some with).  I've got a case where the module is loaded by
a mother task, which ATTACHes its own code with JSTCB=YES, and then
the subtask BALRs into my module.  IDENTIFY doesn't like such things.

Granted this is all self-inflicted pain.  I mentioned the
ATTACH-to-address merely as a wish... I couldn't wait 2-3 years for
such a thing to be universally available anyway.

sas


On Sun, Aug 27, 2017 at 7:41 PM, Peter Relson  wrote:
> As has been mentioned, IDENTIFY can do what is asked for.
> So can binding the load module with appropriate alias(es).
>
> But also so can writing code so that you attach the same entry name but
> the parameter data passed to the attached module tells the code where to
> branch to (whether by a code or an address or some other mechanism).
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Message IRX0006I running an edit macro CLIST

[Paul Gilmartin]

On Mon, 28 Aug 2017 02:59:02 +0100, CM Poncelet wrote:
> 
>As for the 'mysteries', I would guess that IBM published a PTF to
>*enforce* the rule that edit macros should always begin with 'ISREDIT
>MACRO' - and had previously been ignored. ...
>  
For Rexx, at least, I've always experienced an error when there was no
ADDRESS ISREDIT MACRO.  But there may have been some obscure path
where it was not reported for CLISTs.

The behavior was silly.  An entire EXEC could execute successfully then
have an error reported when it exited.

And if the ISPF developers hadn't been Rexx-ignorant, they would have:
o Supported PARSE ARG
o Made the inital command environment ISREDIT rather than TSO.  (That would
  correspond to the way XEDIT macros work in CMS.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Create subtask w/out a load module?

[Paul Gilmartin]

On Mon, 28 Aug 2017 09:33:02 -0400, Steve Smith wrote:

>I've got cases where the module is copied into CSA (w/o benefit of
>DYNLPA, and some with).  I've got a case where the module is loaded by
>a mother task, which ATTACHes its own code with JSTCB=YES, and then
>the subtask BALRs into my module.  IDENTIFY doesn't like such things.
> 
I once (24-bit era) wrote an ATTACHME program which loaded R15 with its
first argument; advanced R1 to the second, and branched.

>Granted this is all self-inflicted pain.  I mentioned the
>ATTACH-to-address merely as a wish... 
> 
For me, it was an old wish.

Perhaps I was anticipating BPX1FRK.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

:Re: Message IRX0006I running an edit macro CLIST

[Jesse 1 Robinson]

That is exactly the case. Like most (maybe all) edit macros), JEM is executed 
directly on the command line. Running it as TSO command (tso jem) would fail to 
establish the proper connection to ISPF. I tried that and got 

EDIT MACRO ERROR
EDIT MACRO INITIALIZATION FAILURE.  CHECK EDIT MACRO CLIST.

I did not see Paul Feller's post except as quoted by CM Poncelet. As CM notes, 
there are two parms: DSJNAME and PARMSTR. It seems odd that one is defined on 
the PROC statement and the other on the ISREDIT MACRO statement, but that's the 
way it's supplied to the customer. 

I have no problem learning that an old loophole has been closed. But closed is 
closed, and what fails in one place should fail everywhere with the fix is 
place. The person who first reported the problem here is a true mainframe 
veteran. He uses JEM more than anyone else I know. 
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Sunday, August 27, 2017 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Message IRX0006I running an edit macro CLIST

Typically the user is EDITing a PDS Member with JCL and enters JEM on the 
command line

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of CM Poncelet
> Sent: Sunday, August 27, 2017 7:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Message IRX0006I running an edit macro CLIST
> 
> There are two parms for this Clist: DSJNAME and PARMSTR. How is JEM invoked?
> (E.g. it could be invoked as "TSO JEM HLQ.DSJN1.THEREST MACPARM2".)
> 
> On 27/08/2017 18:25, Feller, Paul wrote:
> > One last comment.  We run the same software and have not had an 
> > issue in
> three different SYSPLEX environments.  I looked to the most recent 
> versions of the software we have.  The JEM CLIST is shipped that way from the 
> vendor.
> Very interesting.
> >
> >
> > BROWSESYSI.JOBSCAN.R790.AJJSCLST.HS(JEM) - 01. Line 00 Col 001
> 080
> >  Command ===>  Scroll ===>
> CSR
> > * Top of Data
> *
> >   PROC 0  DJSNAME(X.X)
> >   CONTROL END(ENDO) NOMSG NOFLUSH
> > /*CONTROL END(ENDO) MSG LIST CONLIST SYMLIST NOFLUSH /*S80725*/
> >   ISREDIT MACRO (PARMSTR)
> >
> >   IF &DJSNAME = &STR(X.X) THEN +
> > DO
> > ISPEXEC SETMSG MSG(JM022R)/*JTE30780*/
> > GOTO ENDING
> > ENDO
> >
> > /*    ALLOCATE RUN CONTROL LIBRARY
> >ISPEXEC SELECT PGM(J00YCKAL) PARM(JLRCL)   /*JTE30780*/
> >IF &LASTCC NE 0 THEN +
> >  DO
> >SET &RCLALC = 'N'  /*813647 */
> >ALLOC DDN(JLRCL) DSN('&DJSNAME..SJJSPARM') SHR
> >  ENDO
> >
> > /*    CALL THE JEM SUPERVISOR 
> >   ISPEXEC SELECT PGM(J0AYEMU) PARM(PR(E) &PARMSTR) 
> > /*JTE30780*/
> >
> >   ENDING: +
> >   ISPEXEC VGET (ZSPLIT)
> >   IF &STR(&ZSPLIT) = &STR(YES) THEN +
> > EXIT
> >   IF &RCLALC = 'N' THEN FREE DDN(JLRCL)
> >   EXIT
> >  Bottom of Data
> > ***
> >
> > Thanks..
> >
> > Paul Feller
> > AGT Mainframe Technical Support
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
> > Sent: Sunday, August 27, 2017 12:11
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Message IRX0006I running an edit macro CLIST
> >
> > I never knew of this restriction on edit macros. Looking through the 
> > same
> library for others, I find a few other CLISTs that have 'PROC' at the 
> top; most do not. It looks like JEM was constructed to allow an 
> alternate load library to be specified on invocation for testing 
> purposes. I removed the PROC statement and now it works. BTW I did not 
> take the step of closing the opening comment with '*/'; that is not 
> required for CLIST in general. Also, there is no other copy of JEM except 
> this one in SYSPROC.
> >
> > So mysteries remain. My favorite user complaint: this used to work 
> > and now
> it doesn't; what happened? Even more mysterious, the same CLIST 
> continues to work on other sysplexes at the same z/OS maintenance 
> level. In any case, the immediate problem is solved, for which I'm once again 
> grateful to this List.
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 3

How to require all secure FTP except to one subnet?

[SUBSCRIBE IBM-MAIN Mary Vollmer]

I am implementing TLS 1.2 via AT-TLS and have a requirement to secure all FTPs 
using this protocol except for the exchanges occurring via the hipersocket.

I am manually coding the policy since I don't have zOSMF configured.  In my 
policy I have a rule for my unsecure connections, coding both LocalAddr and 
RemoteAddr with that of our hipersocket subnet.  It has a priority of 100 and 
is first in the policy.  I also have a rule for secure connections with no 
LocalAddr or RemoteAddr with a priority of 10.

In my FTPDATA:
   When I specify SECURE_FTP REQUIRED, all unsecure attempts (inbound and 
outbound) fail - including those via the hipersocket.


   When I specify SECURE_FTP ALLOWED, all unsecure attempts (inbound and 
outbound) are successful - even those NOT using the hipersocket.  

I turned on tracing and see the rules selected are as I would have expected but 
it appears the SECURE_FTP parm in FTP data rules, regardless of what's in the 
policy.  

Does anyone know if it's possible to do what I am trying do to with one TCPIP 
stack?

Thanks,
Mary Vollmer 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Looking for mainframe shops Lexington/Cincinnati

[Donald J]

Toyota used to be in Georgetown KY.
WPAFB used to hire a lot of mainframe contractors.
There are also a couple of insurance companies in Cincinnati. 
Cincinnati bell possibly.
State of KY might have a mainframe in Frankfort.
There is a federal site in Fort Knox with mainframes, might be Army.
 
 

Sent: Saturday, August 26, 2017 at 9:59 PM
From: "Joel M Ivey" 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Looking for mainframe shops Lexington/Cincinnati
Would appreciate info on zos shops in Lexington KY and Cincinnati OH, for 
possible relo.
What mainframe shops are there???

Thanks,
Joel
Columbia SC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Looking for mainframe shops Lexington/Cincinnati

[Burrell, Todd]

I believe Kroger has a shop in Cincinnati. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Donald J
Sent: Monday, August 28, 2017 1:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for mainframe shops Lexington/Cincinnati

Toyota used to be in Georgetown KY.
WPAFB used to hire a lot of mainframe contractors.
There are also a couple of insurance companies in Cincinnati. 
Cincinnati bell possibly.
State of KY might have a mainframe in Frankfort.
There is a federal site in Fort Knox with mainframes, might be Army.
 
 

Sent: Saturday, August 26, 2017 at 9:59 PM
From: "Joel M Ivey" 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Looking for mainframe shops Lexington/Cincinnati Would appreciate info 
on zos shops in Lexington KY and Cincinnati OH, for possible relo.
What mainframe shops are there???

Thanks,
Joel
Columbia SC

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Looking for mainframe shops Lexington/Cincinnati

[Rob Schramm]

Vantiv has been looking for a capacity planner for a while.

On Mon, Aug 28, 2017, 1:31 PM Burrell, Todd  wrote:

> I believe Kroger has a shop in Cincinnati.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Donald J
> Sent: Monday, August 28, 2017 1:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Looking for mainframe shops Lexington/Cincinnati
>
> Toyota used to be in Georgetown KY.
> WPAFB used to hire a lot of mainframe contractors.
> There are also a couple of insurance companies in Cincinnati.
> Cincinnati bell possibly.
> State of KY might have a mainframe in Frankfort.
> There is a federal site in Fort Knox with mainframes, might be Army.
>
>
>
> Sent: Saturday, August 26, 2017 at 9:59 PM
> From: "Joel M Ivey" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Looking for mainframe shops Lexington/Cincinnati Would appreciate
> info on zos shops in Lexington KY and Cincinnati OH, for possible relo.
> What mainframe shops are there???
>
> Thanks,
> Joel
> Columbia SC
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> This email transmission and any accompanying attachments may contain CSX
> privileged and confidential information intended only for the use of the
> intended addressee. Any dissemination, distribution, copying or action
> taken in reliance on the contents of this email by anyone other than the
> intended recipient is strictly prohibited. If you have received this email
> in error please immediately delete it and notify sender at the above CSX
> email address. Sender and CSX accept no liability for any damage caused
> directly or indirectly by receipt of this email.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How to require all secure FTP except to one subnet?

[Nims,Alva John (Al)]

First, I am going to be the one to tell you to go over to the IBM-TCPIP list:
"For IBMTCP-L subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO IBMTCP-L"

That said:
SECURE_FTP is as simple as it says, "ALLOWED" basically states that clients can 
log in using a security mechanism, but it is NOT REQUIRED.  If you code 
"REQUIRED" then the client MUST log in using a security mechanism, if the 
client is another z/OS system then " SECURE_MECHANISM TLS" would be the option 
to look at, other software, well start digging.

I personally do not know if access via subnet can be controlled at the z/OS 
TCP/IP level, but that is mostly because we turned that kind of control over to 
our network personnel.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of SUBSCRIBE IBM-MAIN Mary Vollmer
Sent: Monday, August 28, 2017 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to require all secure FTP except to one subnet?

I am implementing TLS 1.2 via AT-TLS and have a requirement to secure all FTPs 
using this protocol except for the exchanges occurring via the hipersocket.

I am manually coding the policy since I don't have zOSMF configured.  In my 
policy I have a rule for my unsecure connections, coding both LocalAddr and 
RemoteAddr with that of our hipersocket subnet.  It has a priority of 100 and 
is first in the policy.  I also have a rule for secure connections with no 
LocalAddr or RemoteAddr with a priority of 10.

In my FTPDATA:
   When I specify SECURE_FTP REQUIRED, all unsecure attempts (inbound and 
outbound) fail - including those via the hipersocket.


   When I specify SECURE_FTP ALLOWED, all unsecure attempts (inbound and 
outbound) are successful - even those NOT using the hipersocket.  

I turned on tracing and see the rules selected are as I would have expected but 
it appears the SECURE_FTP parm in FTP data rules, regardless of what's in the 
policy.  

Does anyone know if it's possible to do what I am trying do to with one TCPIP 
stack?

Thanks,
Mary Vollmer 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How to require all secure FTP except to one subnet?

[Cieri, Anthony]

It is certainly possible with one TCP/IP stack.We do it!!!

However, we do use two separate FTP tasks, one is secure (FTPS) and one 
is NOT (FTPD). You could then code a FTCHKIP exit for the non-secure FTP task 
to only allow login from the hipersocket address range.
If the two FTP tasks run on the same LPAR, then they will need 
different ports!!

Hth
Tony 
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of SUBSCRIBE IBM-MAIN Mary Vollmer
Sent: Monday, August 28, 2017 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to require all secure FTP except to one subnet?

I am implementing TLS 1.2 via AT-TLS and have a requirement to secure all FTPs 
using this protocol except for the exchanges occurring via the hipersocket.

I am manually coding the policy since I don't have zOSMF configured.  In my 
policy I have a rule for my unsecure connections, coding both LocalAddr and 
RemoteAddr with that of our hipersocket subnet.  It has a priority of 100 and 
is first in the policy.  I also have a rule for secure connections with no 
LocalAddr or RemoteAddr with a priority of 10.

In my FTPDATA:
   When I specify SECURE_FTP REQUIRED, all unsecure attempts (inbound and 
outbound) fail - including those via the hipersocket.


   When I specify SECURE_FTP ALLOWED, all unsecure attempts (inbound and 
outbound) are successful - even those NOT using the hipersocket.  

I turned on tracing and see the rules selected are as I would have expected but 
it appears the SECURE_FTP parm in FTP data rules, regardless of what's in the 
policy.  

Does anyone know if it's possible to do what I am trying do to with one TCPIP 
stack?

Thanks,
Mary Vollmer 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Looking for mainframe shops Lexington/Cincinnati

[Steve Smith]

I forgot about Kroger, and P&G.  Both are headquartered here.  US Bank
may still have some operations in town (vestiges of a big local bank
they acquired many years ago).  Great American Insurance may be a
player.

To be honest, I'm ridiculously uninformed about the place I've lived
for 30 years.  For the past five years, I've been a remote hermit, and
have no colleagues, much less offices, within 500 miles.  (afaik)

sas

On Mon, Aug 28, 2017 at 1:31 PM, Burrell, Todd  wrote:
> I believe Kroger has a shop in Cincinnati.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Linking module in SMP/E with ++JCL

[Fred Kaptein]

Hello,
I am having problem applying a USERMOD when using SMP/E.
I have a ++JCLIN statement within the USERMOD to do a LINK.
The USERMOD RECEIVES and APPLYs okay, but the LINK is not done.
The JCL within the ++JCLIN statement is okay, I can run it outside of SMP/E and 
it LINKs successfully.

Can anyone tell me why the following usermod does not link.

++USERMOD (LM2TBT0)  
++VER (Z038) FMID(HDZ2210)   
++JCLIN. 
//IGGPRE00 JOB (SOFTN002),'IGGPRE00 ',   
// CLASS=K,TIME=5,NOTIFY=&SYSUID,MSGCLASS=X  
//*  
//* EDIT ASSEMBLE IGGPRE00 & LINK TO LPALIB  
//*  
//ACFLINK EXEC PGM=IEWL, ACF2 MODULE LINK PROCEDURE  
//PARM='RENT,LET,LIST,XREF,SIZE=(512K,96K)'  
//SYSLMOD DD DISP=SHR,DSN=SYS1.LPALIB
//SYSUT1 DD UNIT=SYSDA,SPACE=(TRK,(10,10))   
//SYSPRINT DD SYSOUT=*   
//ACFMOD DD DISP=SHR,DSN=SYS2A.CA.LINKLIB
//SYSLIN DD *
  INCLUDE ACFMOD(ACF$GCVT) 
  INCLUDE ACFMOD(ACF00GCB) 
  INCLUDE LPALIB(IGGPRE00) 
  ENTRY IGGPRE00   
  NAME IGGPRE00(R) 
++SRC(IGGPRE00) DISTLIB(AVPSSRC).  
IGGPRE00 TITLE 'DF/DS PREPROCESSING EXIT FOR NEW DASD ALLOCATION' 
  "  source statements "

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Linking module in SMP/E with ++JCL

[Jesse 1 Robinson]

I don't know what messages you are seeing, but we have several analogous 
usermods. First problem I see is that the +USERMOD is missing a closing period. 
++JCLIN is a separate statement that should also have its own period. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Fred Kaptein
Sent: Monday, August 28, 2017 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Linking module in SMP/E with ++JCL

Hello,
I am having problem applying a USERMOD when using SMP/E.
I have a ++JCLIN statement within the USERMOD to do a LINK.
The USERMOD RECEIVES and APPLYs okay, but the LINK is not done.
The JCL within the ++JCLIN statement is okay, I can run it outside of SMP/E and 
it LINKs successfully.

Can anyone tell me why the following usermod does not link.

++USERMOD (LM2TBT0)  
++VER (Z038) FMID(HDZ2210)   
++JCLIN. 
//IGGPRE00 JOB (SOFTN002),'IGGPRE00 ',   
// CLASS=K,TIME=5,NOTIFY=&SYSUID,MSGCLASS=X  
//*  
//* EDIT ASSEMBLE IGGPRE00 & LINK TO LPALIB  
//*  
//ACFLINK EXEC PGM=IEWL, ACF2 MODULE LINK PROCEDURE  
//PARM='RENT,LET,LIST,XREF,SIZE=(512K,96K)'  
//SYSLMOD DD DISP=SHR,DSN=SYS1.LPALIB
//SYSUT1 DD UNIT=SYSDA,SPACE=(TRK,(10,10))   
//SYSPRINT DD SYSOUT=*   
//ACFMOD DD DISP=SHR,DSN=SYS2A.CA.LINKLIB
//SYSLIN DD *
  INCLUDE ACFMOD(ACF$GCVT) 
  INCLUDE ACFMOD(ACF00GCB) 
  INCLUDE LPALIB(IGGPRE00) 
  ENTRY IGGPRE00   
  NAME IGGPRE00(R) 
++SRC(IGGPRE00) DISTLIB(AVPSSRC).  
IGGPRE00 TITLE 'DF/DS PREPROCESSING EXIT FOR NEW DASD ALLOCATION' 
  "  source statements 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Linking module in SMP/E with ++JCL

[Fred Kaptein]

Sorry, there is a period in the ++USERMOD statement.
++USERMOD (LM2TBT0). 

There are no error messages, the USERMOD is RECEIVED and APPLIED successfully. 
However, it does not link.

SYSMOD STATUS REPORT FOR APPLY PROCESSING  SYSMODS APPLIED  - 1
SYSMOD   STATUSTYPE  FMID

LM2TBT0  APPLIED   USERMOD   HDZ2210 


ELEMENT  ELEMENT ELEMENTCURRENTCURRENTDISTLIB  SYSLIB  
ASSEM   LOAD   LMOD SYSMOD SYSMOD 
TYPENAME  STATUS  FMID  RMID  LIBRARY 
LIBRARY NAMES   MODULE  SYSLIB   NAME STATUS 
  
SRC IGGPRE00APPLIED HDZ2210LM2TBT0 AVPSSRC SMPSTS   
 IGGPRE00IGGPRE00  LPALIBLM2TBT0APPLIED

note there is no MOD element

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Linking module in SMP/E with ++JCL

[Steely.Mark]

Have you tried the ASSEM option on the apply. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Fred Kaptein
Sent: Monday, August 28, 2017 4:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linking module in SMP/E with ++JCL

Sorry, there is a period in the ++USERMOD statement.
++USERMOD (LM2TBT0). 

There are no error messages, the USERMOD is RECEIVED and APPLIED successfully. 
However, it does not link.

SYSMOD STATUS REPORT FOR APPLY PROCESSING  SYSMODS APPLIED  - 1
SYSMOD   STATUSTYPE  FMID

LM2TBT0  APPLIED   USERMOD   HDZ2210 


ELEMENT  ELEMENT ELEMENTCURRENTCURRENTDISTLIB  SYSLIB  
ASSEM   LOAD   LMOD SYSMOD SYSMOD 
TYPENAME  STATUS  FMID  RMID  LIBRARY 
LIBRARY NAMES   MODULE  SYSLIB   NAME STATUS 
  
SRC IGGPRE00APPLIED HDZ2210LM2TBT0 AVPSSRC SMPSTS   
 IGGPRE00IGGPRE00  LPALIBLM2TBT0APPLIED

note there is no MOD element

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Linking module in SMP/E with ++JCL

[Jesse 1 Robinson]

I can't put my finger on it, but you seem to have a lot of lines that you don't 
need. In particular, you don't need a job card. Here's the wrapper for a simple 
SMF exit. It always assembles and links the module. A MOD statement is implied 
by the JCLIN. 

//SMPPTFIN DD   DATA,DLM=$$   
++USERMOD (SMFACT1) REWORK(2014171) . 
++VER (Z038)  FMID (HBB7790) .
++JCLIN . 
//SMFACT1  EXEC LINKS,PARM='XREF,LIST,LET,NCAL,RENT'  
//AOSB3DD DISP=SHR,DSN=SYS1.AOSB3 
//SYSLMOD  DD DISP=SHR,DSN=SYS1.LINKLIB   
//SYSLIN   DD *   
  INCLUDE AOSB3(SCEACTLG) 
  MODE AMODE(31) RMODE(ANY)   
  NAME SCEACTLG(R)
++SRC(SCEACTLG) DISTLIB(ASAMPLIB) .   
  full asm source goes here
$$
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, August 28, 2017 2:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Linking module in SMP/E with ++JCL

I don't know what messages you are seeing, but we have several analogous 
usermods. First problem I see is that the +USERMOD is missing a closing period. 
++JCLIN is a separate statement that should also have its own period. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Fred Kaptein
Sent: Monday, August 28, 2017 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Linking module in SMP/E with ++JCL

Hello,
I am having problem applying a USERMOD when using SMP/E.
I have a ++JCLIN statement within the USERMOD to do a LINK.
The USERMOD RECEIVES and APPLYs okay, but the LINK is not done.
The JCL within the ++JCLIN statement is okay, I can run it outside of SMP/E and 
it LINKs successfully.

Can anyone tell me why the following usermod does not link.

++USERMOD (LM2TBT0)  
++VER (Z038) FMID(HDZ2210)   
++JCLIN. 
//IGGPRE00 JOB (SOFTN002),'IGGPRE00 ',   
// CLASS=K,TIME=5,NOTIFY=&SYSUID,MSGCLASS=X  
//*  
//* EDIT ASSEMBLE IGGPRE00 & LINK TO LPALIB  
//*  
//ACFLINK EXEC PGM=IEWL, ACF2 MODULE LINK PROCEDURE  
//PARM='RENT,LET,LIST,XREF,SIZE=(512K,96K)'  
//SYSLMOD DD DISP=SHR,DSN=SYS1.LPALIB
//SYSUT1 DD UNIT=SYSDA,SPACE=(TRK,(10,10))   
//SYSPRINT DD SYSOUT=*   
//ACFMOD DD DISP=SHR,DSN=SYS2A.CA.LINKLIB
//SYSLIN DD *
  INCLUDE ACFMOD(ACF$GCVT) 
  INCLUDE ACFMOD(ACF00GCB) 
  INCLUDE LPALIB(IGGPRE00) 
  ENTRY IGGPRE00   
  NAME IGGPRE00(R) 
++SRC(IGGPRE00) DISTLIB(AVPSSRC).  
IGGPRE00 TITLE 'DF/DS PREPROCESSING EXIT FOR NEW DASD ALLOCATION' 
  "  source statements 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Looking for mainframe shops Lexington/Cincinnati

[Burrell, Todd]

I also believe someone mentioned For Knox - I believe HPE has that contract for 
the mainframe.  Or DXC now that they merged with CSC. 



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Monday, August 28, 2017 4:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for mainframe shops Lexington/Cincinnati

I forgot about Kroger, and P&G.  Both are headquartered here.  US Bank may 
still have some operations in town (vestiges of a big local bank they acquired 
many years ago).  Great American Insurance may be a player.

To be honest, I'm ridiculously uninformed about the place I've lived for 30 
years.  For the past five years, I've been a remote hermit, and have no 
colleagues, much less offices, within 500 miles.  (afaik)

sas

On Mon, Aug 28, 2017 at 1:31 PM, Burrell, Todd  wrote:
> I believe Kroger has a shop in Cincinnati.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Linking module in SMP/E with ++JCL

[Tom Marchant]

On Mon, 28 Aug 2017 15:29:08 -0500, Fred Kaptein wrote:

>Hello,
>I am having problem applying a USERMOD when using SMP/E.
>I have a ++JCLIN statement within the USERMOD to do a LINK.
>The USERMOD RECEIVES and APPLYs okay, but the LINK is not done.
>The JCL within the ++JCLIN statement is okay, I can run it outside of SMP/E 
>and it LINKs successfully.

The way to code JCLIN is to describe how to build a target 
element from distribution libraries.
Your INCLUDE LPALIB(IGGPRE00) should be INCLUDE AOSD0(IGGPRE00).
I'm not sure, but IIRC ACFMOD is a target library, and LINKLIB 
will cause confusion

The DDNAMEs used in the JCLIN should match the low level 
qualifiers of the DSNAME, and these should be Distribution 
library data sets, NOT Target library data sets. It is not 
required that the SYSMODs that provide the elements have 
been accepted.

SYSLMOD is correct, it specifies the target library to contain 
the load module. Only the low level qualifier is significant, and 
saved by SMP/E.

When the DDNAME and the low level qualifier are not the same, 
I don't remember which one SMP/E will use for the DDNAME 
for the bind, but I think it is the LLQ.

I'm not sure, but IIRC ACFMOD is a target library, and 
LINKLIB will cause confusion. I believe that DD statement tells 
SMP/E that the element comes from distribution library LINKLIB. 
This is clearly incorrect.

As Skip noted, you don't need the JOB card. 
Nor do you need SYSPRINT or SYSUT1. 
These are not used by SMP/E

>
>Can anyone tell me why the following usermod does not link.
>
>++USERMOD (LM2TBT0)  
>++VER (Z038) FMID(HDZ2210)   
>++JCLIN. 
>//IGGPRE00 JOB (SOFTN002),'IGGPRE00 ',   
>// CLASS=K,TIME=5,NOTIFY=&SYSUID,MSGCLASS=X  
>//*  
>//* EDIT ASSEMBLE IGGPRE00 & LINK TO LPALIB  
>//*  
>//ACFLINK EXEC PGM=IEWL, ACF2 MODULE LINK PROCEDURE  
>//PARM='RENT,LET,LIST,XREF,SIZE=(512K,96K)'  
>//SYSLMOD DD DISP=SHR,DSN=SYS1.LPALIB
>//SYSUT1 DD UNIT=SYSDA,SPACE=(TRK,(10,10))   
>//SYSPRINT DD SYSOUT=*   
>//ACFMOD DD DISP=SHR,DSN=SYS2A.CA.LINKLIB
>//SYSLIN DD *
>  INCLUDE ACFMOD(ACF$GCVT) 
>  INCLUDE ACFMOD(ACF00GCB) 
>  INCLUDE LPALIB(IGGPRE00) 
>  ENTRY IGGPRE00   
>  NAME IGGPRE00(R) 
>++SRC(IGGPRE00) DISTLIB(AVPSSRC).  
>IGGPRE00 TITLE 'DF/DS PREPROCESSING EXIT FOR NEW DASD ALLOCATION' 
>  "  source statements "
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z14 and zBX

[Ed Jaffe]

On 8/28/2017 1:06 AM, R.S. wrote:

W dniu 2017-08-27 o 17:34, Ed Jaffe pisze:


zBX was a mistake. Every company makes them.


My English is poor, do you mean every company makes zBX or every 
company makes errors?  ;-)))


Every company makes zBX :-D


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: :Re: Message IRX0006I running an edit macro CLIST

[CM Poncelet]

FWIW

The oddity is that there are *no* edit macro statements after "ISREDIT
MACRO (PARMSTR)". So why is an edit macro declared in the Clist?
 
E.g. "ISPEXEC SELECT PGM(J00YCKAL) PARM(JLRCL)" etc.can be issued
directly from the Clist proc and does not need an edit macro to do that.
 
Sure, edit macros are normally invoked from the command line in edit
mode. But they can also be invoked by Clist and REXX procs, and then not
from the command line. So if JEM is a Clist that in turn invokes an edit
macro, then 'TSO JEM + any parms' would be used to invoke JEM as a Clist
(and ISPF option 6 could invoke it simply as 'JEM + any parms'). So, is
JEM meant to be invoked as a Clist ("PROC 0 ...") or as an edit macro
("ISREDIT MACRO ()")?
 
I give up.
 
Cheers, CP
 

On 28/08/2017 15:52, Jesse 1 Robinson wrote:
> That is exactly the case. Like most (maybe all) edit macros), JEM is executed 
> directly on the command line. Running it as TSO command (tso jem) would fail 
> to establish the proper connection to ISPF. I tried that and got 
>
> EDIT MACRO ERROR
> EDIT MACRO INITIALIZATION FAILURE.  CHECK EDIT MACRO CLIST.
>
> I did not see Paul Feller's post except as quoted by CM Poncelet. As CM 
> notes, there are two parms: DSJNAME and PARMSTR. It seems odd that one is 
> defined on the PROC statement and the other on the ISREDIT MACRO statement, 
> but that's the way it's supplied to the customer. 
>
> I have no problem learning that an old loophole has been closed. But closed 
> is closed, and what fails in one place should fail everywhere with the fix is 
> place. The person who first reported the problem here is a true mainframe 
> veteran. He uses JEM more than anyone else I know. 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Lizette Koehler
> Sent: Sunday, August 27, 2017 8:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Message IRX0006I running an edit macro CLIST
>
> Typically the user is EDITing a PDS Member with JCL and enters JEM on the 
> command line
>
> Lizette
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of CM Poncelet
>> Sent: Sunday, August 27, 2017 7:11 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Message IRX0006I running an edit macro CLIST
>>
>> There are two parms for this Clist: DSJNAME and PARMSTR. How is JEM invoked?
>> (E.g. it could be invoked as "TSO JEM HLQ.DSJN1.THEREST MACPARM2".)
>>
>> On 27/08/2017 18:25, Feller, Paul wrote:
>>> One last comment.  We run the same software and have not had an 
>>> issue in
>> three different SYSPLEX environments.  I looked to the most recent 
>> versions of the software we have.  The JEM CLIST is shipped that way from 
>> the vendor.
>> Very interesting.
>>>
>>> BROWSESYSI.JOBSCAN.R790.AJJSCLST.HS(JEM) - 01. Line 00 Col 001
>> 080
>>>  Command ===>  Scroll ===>
>> CSR
>>> * Top of Data
>> *
>>>   PROC 0  DJSNAME(X.X)
>>>   CONTROL END(ENDO) NOMSG NOFLUSH
>>> /*CONTROL END(ENDO) MSG LIST CONLIST SYMLIST NOFLUSH /*S80725*/
>>>   ISREDIT MACRO (PARMSTR)
>>>
>>>   IF &DJSNAME = &STR(X.X) THEN +
>>> DO
>>> ISPEXEC SETMSG MSG(JM022R)/*JTE30780*/
>>> GOTO ENDING
>>> ENDO
>>>
>>> /*    ALLOCATE RUN CONTROL LIBRARY
>>>ISPEXEC SELECT PGM(J00YCKAL) PARM(JLRCL)   /*JTE30780*/
>>>IF &LASTCC NE 0 THEN +
>>>  DO
>>>SET &RCLALC = 'N'  /*813647 */
>>>ALLOC DDN(JLRCL) DSN('&DJSNAME..SJJSPARM') SHR
>>>  ENDO
>>>
>>> /*    CALL THE JEM SUPERVISOR 
>>>   ISPEXEC SELECT PGM(J0AYEMU) PARM(PR(E) &PARMSTR) 
>>> /*JTE30780*/
>>>
>>>   ENDING: +
>>>   ISPEXEC VGET (ZSPLIT)
>>>   IF &STR(&ZSPLIT) = &STR(YES) THEN +
>>> EXIT
>>>   IF &RCLALC = 'N' THEN FREE DDN(JLRCL)
>>>   EXIT
>>>  Bottom of Data
>>> ***
>>>
>>> Thanks..
>>>
>>> Paul Feller
>>> AGT Mainframe Technical Support
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List 
>>> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
>>> Sent: Sunday, August 27, 2017 12:11
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Message IRX0006I running an edit macro CLIST
>>>
>>> I never knew of this restriction on edit macros. Looking through the 
>>> same
>> library for others, I find a few o

Re: :Re: Message IRX0006I running an edit macro CLIST

[Paul Gilmartin]

On Tue, 29 Aug 2017 02:04:25 +0100, CM Poncelet  wrote:

>FWIW
>
>The oddity is that there are *no* edit macro statements after "ISREDIT
>MACRO (PARMSTR)". So why is an edit macro declared in the Clist?
> 
>E.g. "ISPEXEC SELECT PGM(J00YCKAL) PARM(JLRCL)" etc.can be issued
>directly from the Clist proc and does not need an edit macro to do that.
> 
>Sure, edit macros are normally invoked from the command line in edit
>mode. But they can also be invoked by Clist and REXX procs, and then not
>from the command line. So if JEM is a Clist that in turn invokes an edit
>macro, then 'TSO JEM + any parms' would be used to invoke JEM as a Clist
>(and ISPF option 6 could invoke it simply as 'JEM + any parms'). So, is
>JEM meant to be invoked as a Clist ("PROC 0 ...") or as an edit macro
>("ISREDIT MACRO ()")?
> 
>I give up.
> 
In Rexx, I have done in at least one case:
address 'ISREDIT' 'MACRO (Arg1)'   /* Use Edit macro argument  */
if RC<>0 then Arg1 = arg( 1 )  /* else use Rexx argument.  */

... This works in Edit as a macro (just for convenience; it depends on no
ISREDIT commands), TSO READY, IRXJCL, and OMVS, with no code changes.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Looking for mainframe shops Lexington/Cincinnati

[Chris Hoelscher]

Actually fort Knox proper is on the SW side of Louisville - if Louisville falls 
within an acceptable area, I know a shop where system folks are retiring within 
the next year ...

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services

123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Burrell, Todd
Sent: Monday, August 28, 2017 6:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Looking for mainframe shops Lexington/Cincinnati

I also believe someone mentioned For Knox - I believe HPE has that contract for 
the mainframe.  Or DXC now that they merged with CSC. 



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Monday, August 28, 2017 4:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for mainframe shops Lexington/Cincinnati

I forgot about Kroger, and P&G.  Both are headquartered here.  US Bank may 
still have some operations in town (vestiges of a big local bank they acquired 
many years ago).  Great American Insurance may be a player.

To be honest, I'm ridiculously uninformed about the place I've lived for 30 
years.  For the past five years, I've been a remote hermit, and have no 
colleagues, much less offices, within 500 miles.  (afaik)

sas

On Mon, Aug 28, 2017 at 1:31 PM, Burrell, Todd  wrote:
> I believe Kroger has a shop in Cincinnati.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, age, 
disability or
sex. Humana Inc. and its subsidiaries do not exclude people or treat them 
differently
because of race, color, national origin, age, disability or sex.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: :Re: Message IRX0006I running an edit macro CLIST

[CM Poncelet]

*Any* commands that can be issued in a Clist or REXX proc (e.g. "ISPEXEC
SELECT PGM(J00YCKAL) PARM(JLRCL)" etc.)can also be issued in an edit
macro. But *only edit* statements (e.g. "EXCLUDE ALL P'¬'" then "CHANGE
ALL P'.' ' ' NX" etc.) can be issued in edit macros. The point I was
making was that *no* edit commands (that could be issued *only* in edit
macros) were being issued after the "ISREDIT MACRO (PARMSTR)" - which
thus made the "ISREDIT MACRO (PARMSTR)" statement wholly irrelevant
(because no actual *edit* commands then followed it). All the commands
that *did* follow it could be issued in native Clist or REXX, without a
preceding "ISREDIT MACRO" statement.
 
BTW I use "ADDRESS" only for "ADDRESS IPCS", to avoid having to juggle
between "ADDRESS TSO/MVS/ISREDIT/ISPEXEC/whatever-else".
 
Cheers, CP
 


On 29/08/2017 02:13, Paul Gilmartin wrote:
> On Tue, 29 Aug 2017 02:04:25 +0100, CM Poncelet  wrote:
>
>> FWIW
>>
>> The oddity is that there are *no* edit macro statements after "ISREDIT
>> MACRO (PARMSTR)". So why is an edit macro declared in the Clist?
>>  
>> E.g. "ISPEXEC SELECT PGM(J00YCKAL) PARM(JLRCL)" etc.can be issued
>> directly from the Clist proc and does not need an edit macro to do that.
>>  
>> Sure, edit macros are normally invoked from the command line in edit
>> mode. But they can also be invoked by Clist and REXX procs, and then not
> >from the command line. So if JEM is a Clist that in turn invokes an edit
>> macro, then 'TSO JEM + any parms' would be used to invoke JEM as a Clist
>> (and ISPF option 6 could invoke it simply as 'JEM + any parms'). So, is
>> JEM meant to be invoked as a Clist ("PROC 0 ...") or as an edit macro
>> ("ISREDIT MACRO ()")?
>>  
>> I give up.
>>  
> In Rexx, I have done in at least one case:
> address 'ISREDIT' 'MACRO (Arg1)'   /* Use Edit macro argument  */
> if RC<>0 then Arg1 = arg( 1 )  /* else use Rexx argument.  */
>
> ... This works in Edit as a macro (just for convenience; it depends on no
> ISREDIT commands), TSO READY, IRXJCL, and OMVS, with no code changes.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: :Re: Message IRX0006I running an edit macro CLIST

[Paul Gilmartin]

On Tue, 29 Aug 2017 04:37:19 +0100, CM Poncelet wrote:
>
>... made the "ISREDIT MACRO (PARMSTR)" statement wholly irrelevant
>(because no actual *edit* commands then followed it). All the commands
>that *did* follow it could be issued in native Clist or REXX, without a
>preceding "ISREDIT MACRO" statement.
>  
But you might risk a "NOT AN EDIT MACRO" error in its absence.

>BTW I use "ADDRESS" only for "ADDRESS IPCS", to avoid having to juggle
>between "ADDRESS TSO/MVS/ISREDIT/ISPEXEC/whatever-else".
> 
Does this make me the opposite extreme?  In a 432-line Rexx EXEC:

509 $ grep -i address ...
address 'ISREDIT' 'MACRO (Arg1)'   /* Use Edit macro argument  */
address 'ISPEXEC' 'VGET (ZSCREENI) SHARED'
address 'SYSCALL'
address 'SDSF'
address 'SYSCALL' 'open (G.9LOG)' ,
address 'SYSCALL' 'pipe G.9PIPE.'
address 'SYSCALL'
address 'SYSCALL'
address 'SYSCALL'
address 'TSO' 'RECEIVE INDD('arg( 1 )')';  end
address 'MVS' 'EXECIO 1 DISKW' G.9CTRL '( finis stem Content.'
address 'MVS' 'EXECIO 2 DISKW' G.9IEBOUT '(finis stem Header.'
address 'ATTCHMVS' 'IEBGENER PARM1 PARM2'
address 'SYSCALL'
address 'SYSCALL' 'mkdir (Head) 777'  /* less umask */
address 'SYSCALL' 'strerror (errno) (errnojr) emsg.'

... ?  (Mr. Natural sez, Use the right tool for the job.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Peter Hunkeler]

>I believe that with AMODE 31 this should be possible (establishing another
ESTAE routine, when LE is active), because IIRC this is what I did when
calling C and PL/1 routines from APL ...



Is it possible? Yes.
Is it supported by LE? No. Read my comment on Charle's previous thread.


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Peter Hunkeler]

>If I had nothing better to do I would open an RFE on that. Even assuming AMODE 
>31, how can LE assume that the high halves of the registers are of no 
>debugging value? 64-bit register arithmetic -- or even using the high halves 
>of registers as a temporary holding area -- is a valid technique even in the 
>absence of AMODE 64. The C/C++ compiler itself does so.


Have a look at the "Language Environment Programming Guide for 64-bit Virtual 
Addressing Mode" manual, chapter "Chapter 21. Assembler considerations". It has 
some description about AMODE 64 assembler. I browsed it quickly, only. It talks 
about XPLINK convention to be a prerequisite for AMODE 64 assembler in a LE 
supported way. I never did anything with XPLINK, so I cannot say how much 
effort this is, but maybe you can change your assembler code to be LE AMODE 64 
compatible.
While your "SDWA hack" seems to work (today), it is cheating, as you said 
yourself. May hurt you, or your customer in the future.


--
Peter Hunkeler





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN