Re: Determining program name/number of paramaters from called COBOL program

[Tom Brennan]

This may be a bit outside the box (or someone may have mentioned it 
already), but in the past when I wanted to know if someone was using a 
particular program, I'd rename that member to something else and create 
my own front end under the original name, which would spit out a WTO or 
similar and then LINK to the original.


On 9/22/2020 1:53 PM, Bernd Oppolzer wrote:
I've done similar things for other languages (C, PL/1, ASSEMBLER), but 
not for COBOL.


Some remarks:

- the desired name of the caller needs to be specified more precisely.
By examining the save area chain, it is possible to retrieve the entry 
point of the calling procedure
(Reg 15 in the save area), and, given that it is a COBOL program of a 
certain compiler release,
it will be possible to retrieve the name of that program (IIRC, there is 
a control block PPA1,
which is pointed to by an address nearby the entry point ... dont recall 
the details;
should work for most newer LE compilers). Other possibities: the name of 
the load module
which contains the entry point address could be examined (using the CDE 
chain).
This can be done regardless of the compiler release and even the 
language of the caller, BTW.

The results of both approaches may differ.

- in a similar way, it is possible to get the addresses passed as 
parameters to the calling function
(using Reg 1), that is, the addresses that point to the different parts 
of the LINKAGE SECTION.
But it is IMO not possible in the general case to count the number of 
addresses, unless
the COBOL compiler marks the last address with the leftmost bit on 
(which I don't know).

Maybe someone more familiar with COBOL internals could comment on this.
In general, the number of parameters is fixed and is a matter of 
negotiation between
caller and called program. And in this case, there is no need to mark 
the last address.
And then, as a consequence, no way for the caller to determine the right 
number of

addresses at run time.

HTH, kind regards

Bernd


Am 22.09.2020 um 21:24 schrieb Chris Cantrell:

Hello,

I am hoping someone out there can help me with this 'opportunity'.

In a Z/OS enterprise COBOL environment, I want to be able to retrieve 
the calling program name and the number of parms passed to the called 
program from the called program. In other words, program A is executed 
in my batch job and it calls program B passing 5 parms in the using 
statement. I want program B to be able to retrieve the program name 
for program A as well as the number of parms that were passed to it.


I think if I could get to the program stack I could probably figure it 
out from there.


Any assistance that any of you could provide would be greatly 
appreciated.


Thanks!

--
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: Determining program name/number of paramaters from called COBOL program

[Seymour J Metz]

Wrong. That's the job step; the caller may be many levels down.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Tuesday, September 22, 2020 6:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining program name/number of paramaters from called COBOL 
program

Well, he can always look to the JSCB to determine the caller, right?

Joe

On Tue, Sep 22, 2020 at 4:19 PM Seymour J Metz  wrote:

> The parm list won't tell him who's calling him. I wouldn't be surprised if
> the special cases cover his requirements, but until he spells them out, ...
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Joe Monk 
> Sent: Tuesday, September 22, 2020 4:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining program name/number of paramaters from called
> COBOL program
>
> yeah ... but R1 should point to the parm list ... and he would calling this
> assembler stub 1st thing so ...
>
> Joe
>
> On Tue, Sep 22, 2020 at 3:23 PM Seymour J Metz  wrote:
>
> > If the data are not in the called programs then chasing the save areas
> > won't find the data. The basic form of a SAVE is just an STM (24 bit) or
> > similar instructions.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Joe Monk 
> > Sent: Tuesday, September 22, 2020 4:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Determining program name/number of paramaters from called
> > COBOL program
> >
> > he could work his way back thru the saveareas, no?
> >
> > Joe
> >
> > On Tue, Sep 22, 2020 at 3:05 PM Seymour J Metz  wrote:
> >
> > > Standard linkage conventions don't require branching around an
> eyecatcher
> > > or that they eyecatcher be in a standardized format or even include the
> > > module name. So the question is what special cases does the OP need to
> > > handle.
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> behalf
> > > of Joe Monk 
> > > Sent: Tuesday, September 22, 2020 4:00 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Determining program name/number of paramaters from called
> > > COBOL program
> > >
> > > If it's using standard OS linkage, he could use an assembler routine to
> > do
> > > a traceback and get some of the items.
> > >
> > > The problem will come in if passed by value instead of by reference...
> > >
> > > Joe
> > >
> > > On Tue, Sep 22, 2020 at 2:58 PM Seymour J Metz  wrote:
> > >
> > > > I doubt that it's possible in general, certain special cases are
> > > possible.
> > > >
> > > >
> > > > --
> > > > Shmuel (Seymour J.) Metz
> > > > http://mason.gmu.edu/~smetz3
> > > >
> > > >
> > > > 
> > > > From: IBM Mainframe Discussion List  on
> > behalf
> > > > of Chris Cantrell 
> > > > Sent: Tuesday, September 22, 2020 3:24 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Determining program name/number of paramaters from called
> > COBOL
> > > > program
> > > >
> > > > Hello,
> > > >
> > > > I am hoping someone out there can help me with this 'opportunity'.
> > > >
> > > > In a Z/OS enterprise COBOL environment, I want to be able to retrieve
> > the
> > > > calling program name and the number of parms passed to the called
> > program
> > > > from the called program. In other words, program A is executed in my
> > > batch
> > > > job and it calls program B passing 5 parms in the using statement. I
> > want
> > > > program B to be able to retrieve the program name for program A as
> well
> > > as
> > > > the number of parms that were passed to it.
> > > >
> > > > I think if I could get to the program stack I could probably figure
> it
> > > out
> > > > from there.
> > > >
> > > > Any assistance that any of you could provide would be greatly
> > > appreciated.
> > > >
> > > > Thanks!
> > > >
> > > >
> --
> > > > 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: Determining program name/number of paramaters from called COBOL program

[Seymour J Metz]

Yes, but we don't know what he's using. I hope it's not 5734-CB1.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Tuesday, September 22, 2020 6:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining program name/number of paramaters from called COBOL 
program

Well, here is the answer to at least part of the puzzle, if not all...

"You can find the name of the calling programs from a COBOL V5 or V6 program
at run time by using the LE service CEETBCK. For more information, see
the z/OS®
Language Environment® Vendor Interfaces."

https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3SA380688/$file/ceev100_v2r3.pdf

Joe


On Tue, Sep 22, 2020 at 5:42 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 22 Sep 2020 21:51:34 +, Farley, Peter x23353 wrote:
>
> >Current Enterprise COBOL compilers (and back as far as I know, even COBOL
> F-level from MVT) always mark the last parameter address in the address
> list with the bit 0 turned on, though I have not researched what current
> ones do if the last parameter is "BY VALUE".
> >
> >Again for current Enterprise COBOL versions, the LE Vendor Interfaces
> manual available in KC has the PPA1 format and in general how to locate it.
> >
> The answer depends on agreement between the designers of the calling
> and called programs.  Lacking such agreement there's no general
> solution.
>
> C programs called by a POSIX shell can rely on argc, but only because
> that's
> specified in the Standard.
>
> -- 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

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

Re: Determining program name/number of paramaters from called COBOL program

[Seymour J Metz]

You can use CSVQUERY to get the name of the caller's load module, but that 
still won't get you the name of the caller.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Brian Chapman 
Sent: Tuesday, September 22, 2020 8:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining program name/number of paramaters from called COBOL 
program

Correction:  you can chain through the resister save area and use the *caller's
entry point* (not CEECAA)to chain to the caller's PPA and retrieve the
program name.



Thank you,

Brian Chapman


On Tue, Sep 22, 2020 at 7:39 PM Brian Chapman  wrote:

> If the called program is assembler and the caller is COBOL (linked with
> LE), then you can chain through the resister save area and use the CEECAA
> to chain to the caller's PPA and retrieve the program name. This method
> really only works for called assembler programs; don't bother with COBOL.
>
> The number of passed parameters is the easy part. Just use the register
> save area to read the addresses in register 1 looking for the high order
> bit.
>
> On Tue, Sep 22, 2020, 6:50 PM Joe Monk  wrote:
>
>> Well, here is the answer to at least part of the puzzle, if not all...
>>
>> "You can find the name of the calling programs from a COBOL V5 or V6
>> program
>> at run time by using the LE service CEETBCK. For more information, see
>> the z/OS®
>> Language Environment® Vendor Interfaces."
>>
>>
>> https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3SA380688/$file/ceev100_v2r3.pdf
>>
>> Joe
>>
>>
>> On Tue, Sep 22, 2020 at 5:42 PM Paul Gilmartin <
>> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> > On Tue, 22 Sep 2020 21:51:34 +, Farley, Peter x23353 wrote:
>> >
>> > >Current Enterprise COBOL compilers (and back as far as I know, even
>> COBOL
>> > F-level from MVT) always mark the last parameter address in the address
>> > list with the bit 0 turned on, though I have not researched what current
>> > ones do if the last parameter is "BY VALUE".
>> > >
>> > >Again for current Enterprise COBOL versions, the LE Vendor Interfaces
>> > manual available in KC has the PPA1 format and in general how to locate
>> it.
>> > >
>> > The answer depends on agreement between the designers of the calling
>> > and called programs.  Lacking such agreement there's no general
>> > solution.
>> >
>> > C programs called by a POSIX shell can rely on argc, but only because
>> > that's
>> > specified in the Standard.
>> >
>> > -- 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
>>
>

--
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: Determining program name/number of paramaters from called COBOL program

[Farley, Peter x23353]

Which can get very tricky indeed when the CALL is from an input or output exit 
routine of a COBOL internal SORT.  Trying to find your way back through the 
SORT interface routines can be frustrating at best, and impossible at worst.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Chapman
Sent: Tuesday, September 22, 2020 8:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining program name/number of paramaters from called COBOL 
program

Correction:  you can chain through the resister save area and use the *caller's 
entry point* (not CEECAA)to chain to the caller's PPA and retrieve the program 
name.

Thank you,

Brian Chapman


On Tue, Sep 22, 2020 at 7:39 PM Brian Chapman  wrote:

> If the called program is assembler and the caller is COBOL (linked 
> with LE), then you can chain through the resister save area and use 
> the CEECAA to chain to the caller's PPA and retrieve the program name. 
> This method really only works for called assembler programs; don't bother 
> with COBOL.
>
> The number of passed parameters is the easy part. Just use the 
> register save area to read the addresses in register 1 looking for the 
> high order bit.
>
> On Tue, Sep 22, 2020, 6:50 PM Joe Monk  wrote:
>
>> Well, here is the answer to at least part of the puzzle, if not all...
>>
>> "You can find the name of the calling programs from a COBOL V5 or V6 
>> program at run time by using the LE service CEETBCK. For more 
>> information, see the z/OS® Language Environment® Vendor Interfaces."
>>
>>
>> https://urldefense.com/v3/__https://www-01.ibm.com/servers/resourceli
>> nk/svc00100.nsf/pages/zOSV2R3SA380688/$file/ceev100_v2r3.pdf__;!!Ebr-
>> cpPeAnfNniQ8HSAI-g_K5b7VKg!axDL42ZaIQJjblemDbSHZnQhdTAajb-KDr_hnzIti1
>> zjkD_ysD8R-DiKvbel6an7sJvSHA$
>>
>> Joe
>>
>>
>> On Tue, Sep 22, 2020 at 5:42 PM Paul Gilmartin < 
>> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> > On Tue, 22 Sep 2020 21:51:34 +, Farley, Peter x23353 wrote:
>> >
>> > >Current Enterprise COBOL compilers (and back as far as I know, 
>> > >even
>> COBOL
>> > F-level from MVT) always mark the last parameter address in the 
>> > address list with the bit 0 turned on, though I have not researched 
>> > what current ones do if the last parameter is "BY VALUE".
>> > >
>> > >Again for current Enterprise COBOL versions, the LE Vendor 
>> > >Interfaces
>> > manual available in KC has the PPA1 format and in general how to 
>> > locate
>> it.
>> > >
>> > The answer depends on agreement between the designers of the 
>> > calling and called programs.  Lacking such agreement there's no 
>> > general solution.
>> >
>> > C programs called by a POSIX shell can rely on argc, but only 
>> > because that's specified in the Standard.
>> >
-- 

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

Re: Determining program name/number of paramaters from called COBOL program

[Brian Chapman]

Correction:  you can chain through the resister save area and use the *caller's
entry point* (not CEECAA)to chain to the caller's PPA and retrieve the
program name.



Thank you,

Brian Chapman


On Tue, Sep 22, 2020 at 7:39 PM Brian Chapman  wrote:

> If the called program is assembler and the caller is COBOL (linked with
> LE), then you can chain through the resister save area and use the CEECAA
> to chain to the caller's PPA and retrieve the program name. This method
> really only works for called assembler programs; don't bother with COBOL.
>
> The number of passed parameters is the easy part. Just use the register
> save area to read the addresses in register 1 looking for the high order
> bit.
>
> On Tue, Sep 22, 2020, 6:50 PM Joe Monk  wrote:
>
>> Well, here is the answer to at least part of the puzzle, if not all...
>>
>> "You can find the name of the calling programs from a COBOL V5 or V6
>> program
>> at run time by using the LE service CEETBCK. For more information, see
>> the z/OS®
>> Language Environment® Vendor Interfaces."
>>
>>
>> https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3SA380688/$file/ceev100_v2r3.pdf
>>
>> Joe
>>
>>
>> On Tue, Sep 22, 2020 at 5:42 PM Paul Gilmartin <
>> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> > On Tue, 22 Sep 2020 21:51:34 +, Farley, Peter x23353 wrote:
>> >
>> > >Current Enterprise COBOL compilers (and back as far as I know, even
>> COBOL
>> > F-level from MVT) always mark the last parameter address in the address
>> > list with the bit 0 turned on, though I have not researched what current
>> > ones do if the last parameter is "BY VALUE".
>> > >
>> > >Again for current Enterprise COBOL versions, the LE Vendor Interfaces
>> > manual available in KC has the PPA1 format and in general how to locate
>> it.
>> > >
>> > The answer depends on agreement between the designers of the calling
>> > and called programs.  Lacking such agreement there's no general
>> > solution.
>> >
>> > C programs called by a POSIX shell can rely on argc, but only because
>> > that's
>> > specified in the Standard.
>> >
>> > -- 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
>>
>

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

Re: Determining program name/number of paramaters from called COBOL program

[Brian Chapman]

If the called program is assembler and the caller is COBOL (linked with
LE), then you can chain through the resister save area and use the CEECAA
to chain to the caller's PPA and retrieve the program name. This method
really only works for called assembler programs; don't bother with COBOL.

The number of passed parameters is the easy part. Just use the register
save area to read the addresses in register 1 looking for the high order
bit.

On Tue, Sep 22, 2020, 6:50 PM Joe Monk  wrote:

> Well, here is the answer to at least part of the puzzle, if not all...
>
> "You can find the name of the calling programs from a COBOL V5 or V6
> program
> at run time by using the LE service CEETBCK. For more information, see
> the z/OS®
> Language Environment® Vendor Interfaces."
>
>
> https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3SA380688/$file/ceev100_v2r3.pdf
>
> Joe
>
>
> On Tue, Sep 22, 2020 at 5:42 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Tue, 22 Sep 2020 21:51:34 +, Farley, Peter x23353 wrote:
> >
> > >Current Enterprise COBOL compilers (and back as far as I know, even
> COBOL
> > F-level from MVT) always mark the last parameter address in the address
> > list with the bit 0 turned on, though I have not researched what current
> > ones do if the last parameter is "BY VALUE".
> > >
> > >Again for current Enterprise COBOL versions, the LE Vendor Interfaces
> > manual available in KC has the PPA1 format and in general how to locate
> it.
> > >
> > The answer depends on agreement between the designers of the calling
> > and called programs.  Lacking such agreement there's no general
> > solution.
> >
> > C programs called by a POSIX shell can rely on argc, but only because
> > that's
> > specified in the Standard.
> >
> > -- 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
>

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

Re: Determining program name/number of paramaters from called COBOL program

[Joe Monk]

Well, here is the answer to at least part of the puzzle, if not all...

"You can find the name of the calling programs from a COBOL V5 or V6 program
at run time by using the LE service CEETBCK. For more information, see
the z/OS®
Language Environment® Vendor Interfaces."

https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3SA380688/$file/ceev100_v2r3.pdf

Joe


On Tue, Sep 22, 2020 at 5:42 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 22 Sep 2020 21:51:34 +, Farley, Peter x23353 wrote:
>
> >Current Enterprise COBOL compilers (and back as far as I know, even COBOL
> F-level from MVT) always mark the last parameter address in the address
> list with the bit 0 turned on, though I have not researched what current
> ones do if the last parameter is "BY VALUE".
> >
> >Again for current Enterprise COBOL versions, the LE Vendor Interfaces
> manual available in KC has the PPA1 format and in general how to locate it.
> >
> The answer depends on agreement between the designers of the calling
> and called programs.  Lacking such agreement there's no general
> solution.
>
> C programs called by a POSIX shell can rely on argc, but only because
> that's
> specified in the Standard.
>
> -- 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: Determining program name/number of paramaters from called COBOL program

[Paul Gilmartin]

On Tue, 22 Sep 2020 21:51:34 +, Farley, Peter x23353 wrote:

>Current Enterprise COBOL compilers (and back as far as I know, even COBOL 
>F-level from MVT) always mark the last parameter address in the address list 
>with the bit 0 turned on, though I have not researched what current ones do if 
>the last parameter is "BY VALUE".
>
>Again for current Enterprise COBOL versions, the LE Vendor Interfaces manual 
>available in KC has the PPA1 format and in general how to locate it.
> 
The answer depends on agreement between the designers of the calling
and called programs.  Lacking such agreement there's no general
solution.

C programs called by a POSIX shell can rely on argc, but only because that's
specified in the Standard.

-- gil

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

Re: Determining program name/number of paramaters from called COBOL program

[Farley, Peter x23353]

"As soon as you allow by-value parms, you can completely forget the leftmost 
bit technique to mark the last parameter (address)."

Not necessarily.  One technique I have seen used elsewhere Is to add a 'dummy" 
last parameter of X'8000' to mark the end of the list, but I do not know if 
COBOL and/or LE use this technique.

Obviously both caller and called have to respect that convention.

COBOL could also copy the BY VALUE parameter to a compiler-allocated temp 
storage area and pass the address of that area instead of the source area.  For 
a large table or record area that could get quite expensive in CPU time if the 
call is done frequently, but it is at least transparent to the called program 
who does not have to know whether the value was passed by value or by 
reference.  Again, I don’t know if any version of COBOL that supports BY VALUE 
paremeters uses that technique.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bernd Oppolzer
Sent: Tuesday, September 22, 2020 6:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining program name/number of paramaters from called COBOL 
program

Am 22.09.2020 um 23:51 schrieb Farley, Peter x23353:
> Current Enterprise COBOL compilers (and back as far as I know, even COBOL 
> F-level from MVT) always mark the last parameter address in the address list 
> with the bit 0 turned on, though I have not researched what current ones do 
> if the last parameter is "BY VALUE".

Thanks :-)

if you have by-value parameters (not addresses), then you're stuck; by-value 
integers, for example - s9(9) comp in COBOL speech - can be positive or 
negative and have the leftmost bit set off or on, so examining the "addresses" 
(which are in fact not addresses in this case) leads nowhere.

Same goes for PL/1 BYVALUE parameters.

As soon as you allow by-value parms, you can completely forget the leftmost bit 
technique to mark the last parameter (address).

That's why C, for example, does not use nor support the VL bit, although 
variable numbers of parameters are supported (#include ); instead the 
called function must be able to determine the total number of parms from one of 
the leading parms, like in the printf() function, for example.

Kind regards

Bernd

>
> Again for current Enterprise COBOL versions, the LE Vendor Interfaces manual 
> available in KC has the PPA1 format and in general how to locate it.
>
> Peter
--

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

Re: Determining program name/number of paramaters from called COBOL program

[Charles Mills]

If COBOL is like C (and I thought it was) then the words of the vector pointed 
to by R1 on a CALL are all addresses, not values, and so the high-order bit is 
available as a VL end-of-list flag. Does "BY VALUE" in COBOL mean the value is 
in the parm vector? (What about 64-bit values, or long character strings?) Or 
does it mean -- as with C -- that the value passed is a copy of the calling 
program's variable? IOW, the calling linkage is the same -- BY VALUE just means 
that if the called program changes the value the caller never sees the change.

It's interesting -- there is no doc -- at least in the V6.3 P/G -- for "calling 
an assembly language program." I had to go back to COBOL V2 to find any 
reference to calling assembly language programs. The doc there says that 
assembler calling COBOL "should" set the VL bit but does not discuss going the 
other direction. For something that shops do all the time the lack of doc is 
pretty amazing.

I stand by my original reply:
- I strongly suspect you can find the R1 from the entry into the called program 
by chaining back some specific number (perhaps 1) of calls in the save area 
chain, from an assembler routine written for this purpose.
- I strongly suspect COBOL uses the VL bit, so that assembler routine can count 
the passed parameters.
- You can find the EXEC PGM= program name from the JSCB. (And others have 
pointed out you can find the last loaded program name from the CDE chain.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Tuesday, September 22, 2020 2:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining program name/number of paramaters from called COBOL 
program

Current Enterprise COBOL compilers (and back as far as I know, even COBOL 
F-level from MVT) always mark the last parameter address in the address list 
with the bit 0 turned on, though I have not researched what current ones do if 
the last parameter is "BY VALUE".

Again for current Enterprise COBOL versions, the LE Vendor Interfaces manual 
available in KC has the PPA1 format and in general how to locate it.

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

Re: Determining program name/number of paramaters from called COBOL program

[Joe Monk]

Well, he can always look to the JSCB to determine the caller, right?

Joe

On Tue, Sep 22, 2020 at 4:19 PM Seymour J Metz  wrote:

> The parm list won't tell him who's calling him. I wouldn't be surprised if
> the special cases cover his requirements, but until he spells them out, ...
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Joe Monk 
> Sent: Tuesday, September 22, 2020 4:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining program name/number of paramaters from called
> COBOL program
>
> yeah ... but R1 should point to the parm list ... and he would calling this
> assembler stub 1st thing so ...
>
> Joe
>
> On Tue, Sep 22, 2020 at 3:23 PM Seymour J Metz  wrote:
>
> > If the data are not in the called programs then chasing the save areas
> > won't find the data. The basic form of a SAVE is just an STM (24 bit) or
> > similar instructions.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Joe Monk 
> > Sent: Tuesday, September 22, 2020 4:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Determining program name/number of paramaters from called
> > COBOL program
> >
> > he could work his way back thru the saveareas, no?
> >
> > Joe
> >
> > On Tue, Sep 22, 2020 at 3:05 PM Seymour J Metz  wrote:
> >
> > > Standard linkage conventions don't require branching around an
> eyecatcher
> > > or that they eyecatcher be in a standardized format or even include the
> > > module name. So the question is what special cases does the OP need to
> > > handle.
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> behalf
> > > of Joe Monk 
> > > Sent: Tuesday, September 22, 2020 4:00 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Determining program name/number of paramaters from called
> > > COBOL program
> > >
> > > If it's using standard OS linkage, he could use an assembler routine to
> > do
> > > a traceback and get some of the items.
> > >
> > > The problem will come in if passed by value instead of by reference...
> > >
> > > Joe
> > >
> > > On Tue, Sep 22, 2020 at 2:58 PM Seymour J Metz  wrote:
> > >
> > > > I doubt that it's possible in general, certain special cases are
> > > possible.
> > > >
> > > >
> > > > --
> > > > Shmuel (Seymour J.) Metz
> > > > http://mason.gmu.edu/~smetz3
> > > >
> > > >
> > > > 
> > > > From: IBM Mainframe Discussion List  on
> > behalf
> > > > of Chris Cantrell 
> > > > Sent: Tuesday, September 22, 2020 3:24 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Determining program name/number of paramaters from called
> > COBOL
> > > > program
> > > >
> > > > Hello,
> > > >
> > > > I am hoping someone out there can help me with this 'opportunity'.
> > > >
> > > > In a Z/OS enterprise COBOL environment, I want to be able to retrieve
> > the
> > > > calling program name and the number of parms passed to the called
> > program
> > > > from the called program. In other words, program A is executed in my
> > > batch
> > > > job and it calls program B passing 5 parms in the using statement. I
> > want
> > > > program B to be able to retrieve the program name for program A as
> well
> > > as
> > > > the number of parms that were passed to it.
> > > >
> > > > I think if I could get to the program stack I could probably figure
> it
> > > out
> > > > from there.
> > > >
> > > > Any assistance that any of you could provide would be greatly
> > > appreciated.
> > > >
> > > > Thanks!
> > > >
> > > >
> --
> > > > 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
> > >
> > > --
> > > 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 

Re: Determining program name/number of paramaters from called COBOL program

[Bernd Oppolzer]

Am 22.09.2020 um 23:51 schrieb Farley, Peter x23353:

Current Enterprise COBOL compilers (and back as far as I know, even COBOL F-level from 
MVT) always mark the last parameter address in the address list with the bit 0 turned on, 
though I have not researched what current ones do if the last parameter is "BY 
VALUE".


Thanks :-)

if you have by-value parameters (not addresses), then you're stuck;
by-value integers, for example - s9(9) comp in COBOL speech -
can be positive or negative and have the leftmost bit set off or on,
so examining the "addresses" (which are in fact not addresses in this case)
leads nowhere.

Same goes for PL/1 BYVALUE parameters.

As soon as you allow by-value parms, you can completely forget the
leftmost bit technique to mark the last parameter (address).

That's why C, for example, does not use nor support the VL bit,
although variable numbers of parameters are supported (#include 
);

instead the called function must be able to determine the total number
of parms from one of the leading parms, like in the printf() function, 
for example.


Kind regards

Bernd



Again for current Enterprise COBOL versions, the LE Vendor Interfaces manual 
available in KC has the PPA1 format and in general how to locate it.

Peter


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

Re: Caution: "Hacked" email caused the distribution of a potentially harmful attachment

[Seymour J Metz]

The commercial filters are mostly broken in all sorts of fascinating ways. If 
it's an option your best choice is to find a provider competent to select or 
write decent filters.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Tuesday, September 22, 2020 5:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Caution: "Hacked" email caused the distribution of a potentially 
harmful attachment

The commercial e-mail malware filters watch for e-mail where the "from" address 
and the headers do not match.

They did not used to. The *SPAM* filters watched for the mis-match, but not the 
malware filters. The notorious RSA hack began with a spear-phishing e-mail with 
an attachment of an Excel spreadsheet containing a zero-day exploit. RSA's SPAM 
filter caught it! However, two enterprising employees dragged the e-mail out of 
their SPAM folder and opened it and the attached spreadsheet.

Ever since then the malware filter publishers have been watching for this 
mismatch and treating it as potential malware rather than merely potential SPAM.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CM Poncelet
Sent: Tuesday, September 22, 2020 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Caution: "Hacked" email caused the distribution of a potentially 
harmful attachment

Hence, check your trash/deleted folder and then create message filters
for any legitimate emails it contains, then run your message filters
against your trash/deleted folder to move the legitimate emails out of
there and into your "Inbox" folder or whatever other appropriate folders
- and these legitimate emails will then no longer be trapped as
spam/scam emails. What these 'not spam/scam' message filters should
contain and check for is up to you.

--
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: [External] BOF on COBOL and the systems programmer at SHARE

[Pommier, Rex]

Sorry, list, that wasn't supposed to go here.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Tuesday, September 22, 2020 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] BOF on COBOL and the systems programmer at SHARE

Argggh, I just looked at my calendar.  I was about to reply back with 
"sure, but I have no idea what I'd be doing" when I decided to double check my 
calendar.  15 minutes before the BOF is starting I just discovered I need to be 
in an all-IT meeting with the CIO to talk about privacy.  I had best not skip 
this one since they'll be taking attendance.  :-(  

I REALLY wanted to attend this BOF, we're just starting down the 4.2 to 6.3 
migration and the developers and their managers are all freaking out about the 
possibility of sign problems.

Sorry,

Rex

-Original Message-
From: Clark Morris 
Sent: Tuesday, September 22, 2020 4:44 PM
To: Pommier, Rex 
Subject: Re: [External] BOF on COBOL and the systems programmer at SHARE

[Default] On 22 Sep 2020 10:22:36 -0700, in bit.listserv.ibm-main 
rpomm...@sfgmembers.com (Pommier, Rex) wrote:

>Thanks, Clark,
>
>Hoping to see you at 15:15 Central time on Thursday.  :-)

Given my Internet can burp at the most inopportune minute, would you be willing 
to be added as a speaker to help moderate the session after my pre-recorded 
opening introduction.  This BOF is for discussing anything the participants 
want to that is at least somewhat related to my opening remarks.  This is 
insurance because I really intend to be there but in addition to normal 
unreliability, Tropical Storm or Hurricane Teddy is already calling at my house 
and will visit through Wednesday.  After Dorian I got a whole house generator 
so I should be OK.

Thank you 

Clark Morris
>
>Rex
>
>-Original Message-
>From: IBM Mainframe Discussion List  On 
>Behalf Of Clark Morris
>Sent: Tuesday, September 22, 2020 10:36 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: [External] BOF on COBOL and the systems programmer at SHARE
>
>I am giving a BOF on COBOL and the systems programmer on Thursday, 
>September 24 in the last session period - 16:15 Eastern time zone,
>15:15 Central time zone, 14:15, Mountain time zone, 13:15 Pacific time, 17:15 
>Atlantic time zone in Canada and 17:45 in Newfoundland.
>
>There will be a 10 minute introduction (I timed it). It covers items in the 
>COBOL standard not in Enterprise COBOL that might be of use to your shop, 
>facilities in Enterprise COBOL that your shop may have overlooked, caution on 
>setting defaults, and why standards should be reviewed with each new release.  
>The rest of the session will be devoted to whatever the attendees want to 
>discuss and explore.
>
>I have used COBOL to get information from SMF records because it was 
>easier than assembler and my shop didn't have SAS.  I have been 
>responsible for review and recommendation of COBOl and LE defaults in
>2 different shops.  I was active in SHARE starting in 1977 through 2002.
>
>Clark Morris 
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>The information contained in this message is confidential, protected from 
>disclosure and may be legally privileged.  If the reader of this message is 
>not the intended recipient or an employee or agent responsible for delivering 
>this message to the intended recipient, you are hereby notified that any 
>disclosure, distribution, copying, or any action taken or action omitted in 
>reliance on it, is strictly prohibited and may be unlawful.  If you have 
>received this communication in error, please notify us immediately by replying 
>to this message and destroy the material in its entirety, whether in 
>electronic or hard copy format.  Thank you.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: Determining program name/number of paramaters from called COBOL program

[Farley, Peter x23353]

Current Enterprise COBOL compilers (and back as far as I know, even COBOL 
F-level from MVT) always mark the last parameter address in the address list 
with the bit 0 turned on, though I have not researched what current ones do if 
the last parameter is "BY VALUE".

Again for current Enterprise COBOL versions, the LE Vendor Interfaces manual 
available in KC has the PPA1 format and in general how to locate it.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bernd Oppolzer
Sent: Tuesday, September 22, 2020 4:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining program name/number of paramaters from called COBOL 
program

EXTERNAL EMAIL

I've done similar things for other languages (C, PL/1, ASSEMBLER), but not for 
COBOL.

Some remarks:

- the desired name of the caller needs to be specified more precisely.
By examining the save area chain, it is possible to retrieve the entry point of 
the calling procedure (Reg 15 in the save area), and, given that it is a COBOL 
program of a certain compiler release, it will be possible to retrieve the name 
of that program (IIRC, there is a control block PPA1, which is pointed to by an 
address nearby the entry point ... dont recall the details; should work for 
most newer LE compilers). Other possibities: the name of the load module which 
contains the entry point address could be examined (using the CDE chain).
This can be done regardless of the compiler release and even the language of 
the caller, BTW.
The results of both approaches may differ.

- in a similar way, it is possible to get the addresses passed as parameters to 
the calling function (using Reg 1), that is, the addresses that point to the 
different parts of the LINKAGE SECTION.
But it is IMO not possible in the general case to count the number of 
addresses, unless the COBOL compiler marks the last address with the leftmost 
bit on (which I don't know).
Maybe someone more familiar with COBOL internals could comment on this.
In general, the number of parameters is fixed and is a matter of negotiation 
between caller and called program. And in this case, there is no need to mark 
the last address.
And then, as a consequence, no way for the caller to determine the right number 
of addresses at run time.

HTH, kind regards

Bernd


Am 22.09.2020 um 21:24 schrieb Chris Cantrell:
> Hello,
>
> I am hoping someone out there can help me with this 'opportunity'.
>
> In a Z/OS enterprise COBOL environment, I want to be able to retrieve the 
> calling program name and the number of parms passed to the called program 
> from the called program. In other words, program A is executed in my batch 
> job and it calls program B passing 5 parms in the using statement. I want 
> program B to be able to retrieve the program name for program A as well as 
> the number of parms that were passed to it.
>
> I think if I could get to the program stack I could probably figure it out 
> from there.
>
> Any assistance that any of you could provide would be greatly appreciated.
>
> Thanks!
>
> --
> 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 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

Re: [External] BOF on COBOL and the systems programmer at SHARE

[Pommier, Rex]

Argggh, I just looked at my calendar.  I was about to reply back with 
"sure, but I have no idea what I'd be doing" when I decided to double check my 
calendar.  15 minutes before the BOF is starting I just discovered I need to be 
in an all-IT meeting with the CIO to talk about privacy.  I had best not skip 
this one since they'll be taking attendance.  :-(  

I REALLY wanted to attend this BOF, we're just starting down the 4.2 to 6.3 
migration and the developers and their managers are all freaking out about the 
possibility of sign problems.

Sorry,

Rex

-Original Message-
From: Clark Morris  
Sent: Tuesday, September 22, 2020 4:44 PM
To: Pommier, Rex 
Subject: Re: [External] BOF on COBOL and the systems programmer at SHARE

[Default] On 22 Sep 2020 10:22:36 -0700, in bit.listserv.ibm-main 
rpomm...@sfgmembers.com (Pommier, Rex) wrote:

>Thanks, Clark,
>
>Hoping to see you at 15:15 Central time on Thursday.  :-)

Given my Internet can burp at the most inopportune minute, would you be willing 
to be added as a speaker to help moderate the session after my pre-recorded 
opening introduction.  This BOF is for discussing anything the participants 
want to that is at least somewhat related to my opening remarks.  This is 
insurance because I really intend to be there but in addition to normal 
unreliability, Tropical Storm or Hurricane Teddy is already calling at my house 
and will visit through Wednesday.  After Dorian I got a whole house generator 
so I should be OK.

Thank you 

Clark Morris
>
>Rex
>
>-Original Message-
>From: IBM Mainframe Discussion List  On 
>Behalf Of Clark Morris
>Sent: Tuesday, September 22, 2020 10:36 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: [External] BOF on COBOL and the systems programmer at SHARE
>
>I am giving a BOF on COBOL and the systems programmer on Thursday, 
>September 24 in the last session period - 16:15 Eastern time zone,
>15:15 Central time zone, 14:15, Mountain time zone, 13:15 Pacific time, 17:15 
>Atlantic time zone in Canada and 17:45 in Newfoundland.
>
>There will be a 10 minute introduction (I timed it). It covers items in the 
>COBOL standard not in Enterprise COBOL that might be of use to your shop, 
>facilities in Enterprise COBOL that your shop may have overlooked, caution on 
>setting defaults, and why standards should be reviewed with each new release.  
>The rest of the session will be devoted to whatever the attendees want to 
>discuss and explore.
>
>I have used COBOL to get information from SMF records because it was 
>easier than assembler and my shop didn't have SAS.  I have been 
>responsible for review and recommendation of COBOl and LE defaults in
>2 different shops.  I was active in SHARE starting in 1977 through 2002.
>
>Clark Morris 
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>The information contained in this message is confidential, protected from 
>disclosure and may be legally privileged.  If the reader of this message is 
>not the intended recipient or an employee or agent responsible for delivering 
>this message to the intended recipient, you are hereby notified that any 
>disclosure, distribution, copying, or any action taken or action omitted in 
>reliance on it, is strictly prohibited and may be unlawful.  If you have 
>received this communication in error, please notify us immediately by replying 
>to this message and destroy the material in its entirety, whether in 
>electronic or hard copy format.  Thank you.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: STIMERM SVCE

[Attila Fogarasi]

That FRR is for SMF, you might check to see if there has been an earlier
failure, for example message CSV430I in the syslog.  Does your code issue
SMFWTM etc?  Sounds like your STIMERM popped to catch a small timing
window, maybe for asynchronous processing by TCP/IP for your send() that
you say failed.  I'd start by determining what that send() actually did.

On Wed, Sep 23, 2020 at 2:15 AM Pierre Fichaud  wrote:

> The STIMERM is in my code.
> The FRR is inside IEEMB830,08/31/16,UA82681 at +9D4.
>
> Regards, Pierre.
>
> --
> 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: Caution: "Hacked" email caused the distribution of a potentially harmful attachment

[Charles Mills]

The commercial e-mail malware filters watch for e-mail where the "from" address 
and the headers do not match. 

They did not used to. The *SPAM* filters watched for the mis-match, but not the 
malware filters. The notorious RSA hack began with a spear-phishing e-mail with 
an attachment of an Excel spreadsheet containing a zero-day exploit. RSA's SPAM 
filter caught it! However, two enterprising employees dragged the e-mail out of 
their SPAM folder and opened it and the attached spreadsheet.

Ever since then the malware filter publishers have been watching for this 
mismatch and treating it as potential malware rather than merely potential SPAM.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CM Poncelet
Sent: Tuesday, September 22, 2020 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Caution: "Hacked" email caused the distribution of a potentially 
harmful attachment

Hence, check your trash/deleted folder and then create message filters
for any legitimate emails it contains, then run your message filters
against your trash/deleted folder to move the legitimate emails out of
there and into your "Inbox" folder or whatever other appropriate folders
- and these legitimate emails will then no longer be trapped as
spam/scam emails. What these 'not spam/scam' message filters should
contain and check for is up to you.

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

Re: Determining program name/number of paramaters from called COBOL program

[Seymour J Metz]

Chasing the RB chain will identify LINK invocations, but not CALL invocation. 
With luck, everybody usees recognizable eyecatchers in their SAVE macros; if 
not, all bets are off.

Can we safely assume that all of the routines are LE enabled?






--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Mike Hochee 
Sent: Tuesday, September 22, 2020 4:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining program name/number of paramaters from called COBOL 
program

If you can call a small assembler subroutine from the current COBOL pgm being 
executed (may be possible to do this in COBOL as well), use of the following 
fields should help get you current program name, callers name..., callers name, 
etc..  As mentioned, LE may make a difference, not sure. Anyway...

Curr TCB addr (PSATOLD), to curr active RB (TCBRBP), to curr CDE (RBCDE), to 
curr pgm name (CDNAME)   (you are at the end of the chain when RBCDE1=0, and 
you may have to clear the high order byte to get a valid compare)

For the name of previous caller(s)...
Curr TCB addr (PSATOLD), to curr active RB (TCBRBP), to next RB in chain 
(RBLINK), to curr CDE (RBCDE), to pgm name (CDENAME)

HTH,
Mike
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Cantrell
Sent: Tuesday, September 22, 2020 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Determining program name/number of paramaters from called COBOL program

Caution! This message was sent from outside your organization.

Hello,

I am hoping someone out there can help me with this 'opportunity'.

In a Z/OS enterprise COBOL environment, I want to be able to retrieve the 
calling program name and the number of parms passed to the called program from 
the called program. In other words, program A is executed in my batch job and 
it calls program B passing 5 parms in the using statement. I want program B to 
be able to retrieve the program name for program A as well as the number of 
parms that were passed to it.

I think if I could get to the program stack I could probably figure it out from 
there.

Any assistance that any of you could provide would be greatly appreciated.

Thanks!

--
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: Determining program name/number of paramaters from called COBOL program

[Seymour J Metz]

The parm list won't tell him who's calling him. I wouldn't be surprised if the 
special cases cover his requirements, but until he spells them out, ...


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Tuesday, September 22, 2020 4:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining program name/number of paramaters from called COBOL 
program

yeah ... but R1 should point to the parm list ... and he would calling this
assembler stub 1st thing so ...

Joe

On Tue, Sep 22, 2020 at 3:23 PM Seymour J Metz  wrote:

> If the data are not in the called programs then chasing the save areas
> won't find the data. The basic form of a SAVE is just an STM (24 bit) or
> similar instructions.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Joe Monk 
> Sent: Tuesday, September 22, 2020 4:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining program name/number of paramaters from called
> COBOL program
>
> he could work his way back thru the saveareas, no?
>
> Joe
>
> On Tue, Sep 22, 2020 at 3:05 PM Seymour J Metz  wrote:
>
> > Standard linkage conventions don't require branching around an eyecatcher
> > or that they eyecatcher be in a standardized format or even include the
> > module name. So the question is what special cases does the OP need to
> > handle.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Joe Monk 
> > Sent: Tuesday, September 22, 2020 4:00 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Determining program name/number of paramaters from called
> > COBOL program
> >
> > If it's using standard OS linkage, he could use an assembler routine to
> do
> > a traceback and get some of the items.
> >
> > The problem will come in if passed by value instead of by reference...
> >
> > Joe
> >
> > On Tue, Sep 22, 2020 at 2:58 PM Seymour J Metz  wrote:
> >
> > > I doubt that it's possible in general, certain special cases are
> > possible.
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> behalf
> > > of Chris Cantrell 
> > > Sent: Tuesday, September 22, 2020 3:24 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Determining program name/number of paramaters from called
> COBOL
> > > program
> > >
> > > Hello,
> > >
> > > I am hoping someone out there can help me with this 'opportunity'.
> > >
> > > In a Z/OS enterprise COBOL environment, I want to be able to retrieve
> the
> > > calling program name and the number of parms passed to the called
> program
> > > from the called program. In other words, program A is executed in my
> > batch
> > > job and it calls program B passing 5 parms in the using statement. I
> want
> > > program B to be able to retrieve the program name for program A as well
> > as
> > > the number of parms that were passed to it.
> > >
> > > I think if I could get to the program stack I could probably figure it
> > out
> > > from there.
> > >
> > > Any assistance that any of you could provide would be greatly
> > appreciated.
> > >
> > > Thanks!
> > >
> > > --
> > > 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
> >
> > --
> > 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
>

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

Re: Caution: "Hacked" email caused the distribution of a potentially harmful attachment

[Seymour J Metz]

Having to check a spam folder negates the purpose of a spam filter and just 
about guranties losing legitimate messages. Reject apparent spam during the 
SMTP session with an apporopriate messages so legitimate senders know to try 
other channels, and treat anything else as probably legitimate.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of CM 
Poncelet 
Sent: Tuesday, September 22, 2020 5:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Caution: "Hacked" email caused the distribution of a potentially 
harmful attachment

Hence, check your trash/deleted folder and then create message filters
for any legitimate emails it contains, then run your message filters
against your trash/deleted folder to move the legitimate emails out of
there and into your "Inbox" folder or whatever other appropriate folders
- and these legitimate emails will then no longer be trapped as
spam/scam emails. What these 'not spam/scam' message filters should
contain and check for is up to you.

On 22/09/2020 18:42, Seymour J Metz wrote:
> Many of us receive legitimate e-mail from unknown senders, or from known 
> senders with new addresses.
>
> The e-mail addresses in headers are not trustworthy. Digital signatures are 
> only trustworthy if you got the public key from a trusted source.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> CM Poncelet 
> Sent: Monday, September 21, 2020 10:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Caution: "Hacked" email caused the distribution of a potentially 
> harmful attachment
>
> FWIW
>
> (a) Begin by assuming that *all* received emails are spam/scam (and
> define this as the bottom line catch-all message filter) *unless* a
> higher up message filter recognizes both the sender(s)'s and the 'to'
> recipient's addresses as valid.
> (b) The sender's original email address can be found towards the end in
> the message headers, as in the "received from ... for ..." message
> header line.
> (c) Spam/scam emails can be sent to
> https://www.spamcop.net/mcgi?action=loginform for verification, if need be.
>
> The 'trick' to get around spammers/scammers is to use message filters,
> with the bottom line catch-all filter saying something like "if the
> subject does not contain  *and*
> the sender is not @ then save
> the email in the trash/delete folder" - which then ensures that the
> email is never saved in the "Inbox" folder.
>
> A more skilful 'trick' is to have many different email IDs and give out
> a different email ID to every company, individual etc. (and keep a
> record of which email ID was given to whom) - so that, if a spammer or
> scammer gets hold of it, it can be deleted and a replacement new email
> ID can be created ... and then also determine from whom the
> spammer/scammer harvested the old and now deleted email ID. That kills
> off spammers and scammers, because any further emails sent to the old
> email ID just bounce as "undeliverable" and they cannot guess what the
> new email ID is. But that requires owning one or more domain names and
> being able to create/delete email IDs associated with it/them. (I
> have/use more than 200 email IDs across more than 30 domain names.)
>
> HTH.
>
> Cheers, Chris Poncelet (retired sysprog)
>
>
>
> On 22/09/2020 00:04, Bob Bridges wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of Jesse 1 Robinson
>> Sent: Monday, September 21, 2020 17:08
>>
>> JR> The idea of deliberately dumbing down language in spam is preposterous. 
>> First of all I don't understand the purported logic of it.
>>
>> BB> Radoslaw's logic seemed clear to me, but when I set out to spell it out 
>> for you, I began to wonder whether I'd mistaken it.  He wrote "a method to 
>> filter out bright people and leave only the fools", which I interpreted this 
>> way:  Intelligent people (according to Radoslaw) are less likely to produce 
>> profit for the scammer, in the long run.  If the scam is written badly, an 
>> intelligent person is more likely to throw it out, and thus less likely to 
>> waste the scammer's time with replies that will in the end lead nowhere.  
>> Fools, meanwhile, will not notice (or notice less) the atrocious writing, 
>> and thus be more likely to proceed.
>>
>> I'll leave it to him to say whether I read him correctly.  But ~if~ that is 
>> indeed the scammer's motive for writing badly, I think the scammer isn't 
>> thinking very clearly.
>>
>> The next part of your comment I think is just a confusion about who said 
>> what.  I said Nigerians are mostly capable of better English than I see in 
>> "Nigerian old ministers' " emails, but that's just a side comment, not part 
>> of Radoslaw's reasoning.
>>
>> JR> More important, while English is an official 

Re: BOF on COBOL and the systems programmer at SHARE

[Pommier, Rex]

Are they recording BOFs or just regularly scheduled sessions?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Richards, Robert B.
Sent: Tuesday, September 22, 2020 1:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: BOF on COBOL and the systems programmer at SHARE

Not to mention all sessions are recorded! 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Tuesday, September 22, 2020 2:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BOF on COBOL and the systems programmer at SHARE

No good deed goes unpunished.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, September 22, 2020 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BOF on COBOL and the systems programmer at SHARE

On Tue, 22 Sep 2020 12:36:10 -0300, Clark Morris wrote:

>I am giving a BOF on COBOL and the systems programmer on Thursday, 
>September 24 in the last session period - 16:15 Eastern time zone,
>15:15 Central time zone, 14:15, Mountain time zone, 13:15 Pacific time,
>17:15 Atlantic time zone in Canada and 17:45 in Newfoundland.
> 
Couldn't you simply say GMT?  What time in Arizona?  Hawaii?
The Navajo Nation?  ...

--
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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: Any IMS group?

[CM Poncelet]

The IMS group is at im...@imslistserv.bmc.com.

On 22/09/2020 19:30, Lizette Koehler wrote:
> There is a list for almost all activities on the Mainframe.  A internet 
> search on IMS LIST would pull it up 
>
> IMS   http://imslistserv.bmc.com/scripts/wa-BMC.exe?A0=ims-l
>
> Lizette 
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> johnnydeep san
> Sent: Tuesday, September 22, 2020 7:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Any IMS group?
>
> Hi,
>
> Do we have any groups for the IMS  group to discuss some Admin stuff? .
>
> Regards,
> JD
>
> --
> 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: Caution: "Hacked" email caused the distribution of a potentially harmful attachment

[CM Poncelet]

Hence, check your trash/deleted folder and then create message filters
for any legitimate emails it contains, then run your message filters
against your trash/deleted folder to move the legitimate emails out of
there and into your "Inbox" folder or whatever other appropriate folders
- and these legitimate emails will then no longer be trapped as
spam/scam emails. What these 'not spam/scam' message filters should
contain and check for is up to you.

On 22/09/2020 18:42, Seymour J Metz wrote:
> Many of us receive legitimate e-mail from unknown senders, or from known 
> senders with new addresses.
>
> The e-mail addresses in headers are not trustworthy. Digital signatures are 
> only trustworthy if you got the public key from a trusted source.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> CM Poncelet 
> Sent: Monday, September 21, 2020 10:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Caution: "Hacked" email caused the distribution of a potentially 
> harmful attachment
>
> FWIW
>
> (a) Begin by assuming that *all* received emails are spam/scam (and
> define this as the bottom line catch-all message filter) *unless* a
> higher up message filter recognizes both the sender(s)'s and the 'to'
> recipient's addresses as valid.
> (b) The sender's original email address can be found towards the end in
> the message headers, as in the "received from ... for ..." message
> header line.
> (c) Spam/scam emails can be sent to
> https://www.spamcop.net/mcgi?action=loginform for verification, if need be.
>
> The 'trick' to get around spammers/scammers is to use message filters,
> with the bottom line catch-all filter saying something like "if the
> subject does not contain  *and*
> the sender is not @ then save
> the email in the trash/delete folder" - which then ensures that the
> email is never saved in the "Inbox" folder.
>
> A more skilful 'trick' is to have many different email IDs and give out
> a different email ID to every company, individual etc. (and keep a
> record of which email ID was given to whom) - so that, if a spammer or
> scammer gets hold of it, it can be deleted and a replacement new email
> ID can be created ... and then also determine from whom the
> spammer/scammer harvested the old and now deleted email ID. That kills
> off spammers and scammers, because any further emails sent to the old
> email ID just bounce as "undeliverable" and they cannot guess what the
> new email ID is. But that requires owning one or more domain names and
> being able to create/delete email IDs associated with it/them. (I
> have/use more than 200 email IDs across more than 30 domain names.)
>
> HTH.
>
> Cheers, Chris Poncelet (retired sysprog)
>
>
>
> On 22/09/2020 00:04, Bob Bridges wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of Jesse 1 Robinson
>> Sent: Monday, September 21, 2020 17:08
>>
>> JR> The idea of deliberately dumbing down language in spam is preposterous. 
>> First of all I don't understand the purported logic of it.
>>
>> BB> Radoslaw's logic seemed clear to me, but when I set out to spell it out 
>> for you, I began to wonder whether I'd mistaken it.  He wrote "a method to 
>> filter out bright people and leave only the fools", which I interpreted this 
>> way:  Intelligent people (according to Radoslaw) are less likely to produce 
>> profit for the scammer, in the long run.  If the scam is written badly, an 
>> intelligent person is more likely to throw it out, and thus less likely to 
>> waste the scammer's time with replies that will in the end lead nowhere.  
>> Fools, meanwhile, will not notice (or notice less) the atrocious writing, 
>> and thus be more likely to proceed.
>>
>> I'll leave it to him to say whether I read him correctly.  But ~if~ that is 
>> indeed the scammer's motive for writing badly, I think the scammer isn't 
>> thinking very clearly.
>>
>> The next part of your comment I think is just a confusion about who said 
>> what.  I said Nigerians are mostly capable of better English than I see in 
>> "Nigerian old ministers' " emails, but that's just a side comment, not part 
>> of Radoslaw's reasoning.
>>
>> JR> More important, while English is an official language in Nigeria, it is 
>> no one's mother tongue. It's learned, mostly in school, to whatever 
>> proficiency the learner can achieve. The average spammer has probably never 
>> stepped inside university. Even secondary school certification is 
>> improbable. Add to that the 'dialectical' difference between Nigerian and 
>> American English makes it unlikely that the most fluent spammer could write 
>> something of undetectable of origin.
>>
>> BB> I don't buy that last part.  I have no idea how many spammers have been 
>> to University, or secondary school, but they can't ~all~ be illiterate and 
>> therefore it's not 

Re: AT-TLS issues with FTP and SSH

[Kirk Wolf]

That will do it!

BTW: AT-TLS has no relationship with IBM z/OS OpenSSH.

On Tue, Sep 22, 2020 at 12:00 PM Lionel B Dyck  wrote:

> Found issue with SSH - I had created (mkdir) the .ssh directory so it had
> the default permissions.  Should have let ssh-keygen create it.
>
> Tried adding logging to pagent for ftp - overloaded with messages and
> reading them now.
>
> Thank you
>
>
> Lionel B. Dyck <
> Website: https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of
> Mike Hochee
> Sent: Tuesday, September 22, 2020 11:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AT-TLS issues with FTP and SSH
>
> Regarding the AT-TLS issue, your pagent is likely encountering a problem in
> the FTP section (of course!).  Look at the log it generates, and if you
> don't have one, add the logging option to the pagent start command. If I
> remember correctly, there's also a verbose setting. I found the logs to be
> extremely useful.
>
> HTH,
> Mike
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lionel B Dyck
> Sent: Tuesday, September 22, 2020 11:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AT-TLS issues with FTP and SSH
>
> Caution! This message was sent from outside your organization.
>
> We just enabled AT-TLS (PAGENT) on a test LPAR and immediately ran into two
> issues:
>
> 1. The FTP Client ceased to work (until we commented the FTP section in the
> pagent_TTLS.conf file)
> a. No issues doing an FTP into this LPAR.
> 2. Git stopped working due to SSH.
>
> A simple test is:ssh mailto:g...@github.com
>
> And for that I'm getting: FOTS3322 Passwords may not be entered from 3270
> terminals
>
> If we stop PAGENT then everything works.
>
> Can anyone offer any pointers/tips/solutions to either of these problems?
>
> Thanks in advance.
>
>
> Lionel B. Dyck <
> Website: https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
> --
> 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
>

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

Re: Caution: "Hacked" email caused the distribution of a potentially harmful attachment

[Charles Mills]

Well, somebody is sure doing a great job of writing English that does not sound 
intelligent. I currently have one in my inbox with a subject line of

"Wait check defrayment in the number of $3288.78  read at once"

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, September 22, 2020 3:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Caution: "Hacked" email caused the distribution of a potentially 
harmful attachment

Bob,
Yes you correctly interpreted my point about the language in scam emails.

However ...it is NOT MY observation. I'm only messenger. This is 
recognized by proffessionals who work (fight) with scam and Internet 
security, and study the problem.
And it is reasonable, not preposterous.

Few remarks:
1. Scam is a business. Yes, it is a crime, but many crimes are 
profitable and well organized. Like drugs.
2. This business is NOT driven by idiots. There are clever people who 
cheats. Charles Ponzi, Jordan Belfort, Bernard Madoff, Zeek Rewards, 
OSGold, PIPS...
3. Assumption that nigerian scam is driven by nigerian poeple is plain 
wrong.
4. Every crime group is clever enough to hire some native speaker to 
edit some short message without errors and dumb mistakes.
5. Nigerian scam is common name for some type of trick and does not 
necessarily mean anything related to Nigeria. In Poland we have scam 
mails from "US Army soldier", usually from some base in Iraq or Germany. 
And there are more scam topics.
6. Most scam emails are in native language of recipient. So, in Poland 
we have emails in polish, nevermind how the "US Army Soldier" learnt 
this language (usually because of polish roots). And phony nigerian 
minister studied in Poland, which sound reasonable, because we have many 
students from Africa and Middle East (and Latin America).

-- 
Radoslaw Skorupka
Lodz, Poland






W dniu 22.09.2020 o 01:04, Bob Bridges pisze:
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jesse 1 Robinson
> Sent: Monday, September 21, 2020 17:08
>
> JR> The idea of deliberately dumbing down language in spam is preposterous. 
> First of all I don't understand the purported logic of it.
>
> BB> Radoslaw's logic seemed clear to me, but when I set out to spell it out 
> for you, I began to wonder whether I'd mistaken it.  He wrote "a method to 
> filter out bright people and leave only the fools", which I interpreted this 
> way:  Intelligent people (according to Radoslaw) are less likely to produce 
> profit for the scammer, in the long run.  If the scam is written badly, an 
> intelligent person is more likely to throw it out, and thus less likely to 
> waste the scammer's time with replies that will in the end lead nowhere.  
> Fools, meanwhile, will not notice (or notice less) the atrocious writing, and 
> thus be more likely to proceed.
>
> I'll leave it to him to say whether I read him correctly.  But ~if~ that is 
> indeed the scammer's motive for writing badly, I think the scammer isn't 
> thinking very clearly.
>
> The next part of your comment I think is just a confusion about who said 
> what.  I said Nigerians are mostly capable of better English than I see in 
> "Nigerian old ministers' " emails, but that's just a side comment, not part 
> of Radoslaw's reasoning.
>
> JR> More important, while English is an official language in Nigeria, it is 
> no one's mother tongue. It's learned, mostly in school, to whatever 
> proficiency the learner can achieve. The average spammer has probably never 
> stepped inside university. Even secondary school certification is improbable. 
> Add to that the 'dialectical' difference between Nigerian and American 
> English makes it unlikely that the most fluent spammer could write something 
> of undetectable of origin.
>
> BB> I don't buy that last part.  I have no idea how many spammers have been 
> to University, or secondary school, but they can't ~all~ be illiterate and 
> therefore it's not unlikely - just the reverse - that some of them will be 
> able to compose a grammatically correct email.  No one said anything about 
> "undetectable"; for verisimilitude you'd want ~some~ degree of "foreign-ness".
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* ...in your bedchamber do not curse a king, and in your sleeping rooms do 
> not curse a rich man, for a bird of the heavens will carry the sound, and the 
> winged creature will make the matter known.  -Ecclesiastes 10:20 */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Bob Bridges
> Sent: Monday, September 21, 2020 10:19 AM
>
> Interesting hypothesis.  I always supposed that they were badly written 
> either because a) scammers don't care (which is perhaps another way of saying 
> they're illiterate, or b) these Nigerian-oil-minister scams actually are 
> written by foreigners whose English is bad - 

Re: Determining program name/number of paramaters from called COBOL program

[Bernd Oppolzer]

I've done similar things for other languages (C, PL/1, ASSEMBLER), but 
not for COBOL.


Some remarks:

- the desired name of the caller needs to be specified more precisely.
By examining the save area chain, it is possible to retrieve the entry 
point of the calling procedure
(Reg 15 in the save area), and, given that it is a COBOL program of a 
certain compiler release,
it will be possible to retrieve the name of that program (IIRC, there is 
a control block PPA1,
which is pointed to by an address nearby the entry point ... dont recall 
the details;
should work for most newer LE compilers). Other possibities: the name of 
the load module
which contains the entry point address could be examined (using the CDE 
chain).
This can be done regardless of the compiler release and even the 
language of the caller, BTW.

The results of both approaches may differ.

- in a similar way, it is possible to get the addresses passed as 
parameters to the calling function
(using Reg 1), that is, the addresses that point to the different parts 
of the LINKAGE SECTION.
But it is IMO not possible in the general case to count the number of 
addresses, unless
the COBOL compiler marks the last address with the leftmost bit on 
(which I don't know).

Maybe someone more familiar with COBOL internals could comment on this.
In general, the number of parameters is fixed and is a matter of 
negotiation between
caller and called program. And in this case, there is no need to mark 
the last address.
And then, as a consequence, no way for the caller to determine the right 
number of

addresses at run time.

HTH, kind regards

Bernd


Am 22.09.2020 um 21:24 schrieb Chris Cantrell:

Hello,

I am hoping someone out there can help me with this 'opportunity'.

In a Z/OS enterprise COBOL environment, I want to be able to retrieve the 
calling program name and the number of parms passed to the called program from 
the called program. In other words, program A is executed in my batch job and 
it calls program B passing 5 parms in the using statement. I want program B to 
be able to retrieve the program name for program A as well as the number of 
parms that were passed to it.

I think if I could get to the program stack I could probably figure it out from 
there.

Any assistance that any of you could provide would be greatly appreciated.

Thanks!

--
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: Determining program name/number of paramaters from called COBOL program

[Joe Monk]

yeah ... but R1 should point to the parm list ... and he would calling this
assembler stub 1st thing so ...

Joe

On Tue, Sep 22, 2020 at 3:23 PM Seymour J Metz  wrote:

> If the data are not in the called programs then chasing the save areas
> won't find the data. The basic form of a SAVE is just an STM (24 bit) or
> similar instructions.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Joe Monk 
> Sent: Tuesday, September 22, 2020 4:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining program name/number of paramaters from called
> COBOL program
>
> he could work his way back thru the saveareas, no?
>
> Joe
>
> On Tue, Sep 22, 2020 at 3:05 PM Seymour J Metz  wrote:
>
> > Standard linkage conventions don't require branching around an eyecatcher
> > or that they eyecatcher be in a standardized format or even include the
> > module name. So the question is what special cases does the OP need to
> > handle.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Joe Monk 
> > Sent: Tuesday, September 22, 2020 4:00 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Determining program name/number of paramaters from called
> > COBOL program
> >
> > If it's using standard OS linkage, he could use an assembler routine to
> do
> > a traceback and get some of the items.
> >
> > The problem will come in if passed by value instead of by reference...
> >
> > Joe
> >
> > On Tue, Sep 22, 2020 at 2:58 PM Seymour J Metz  wrote:
> >
> > > I doubt that it's possible in general, certain special cases are
> > possible.
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> behalf
> > > of Chris Cantrell 
> > > Sent: Tuesday, September 22, 2020 3:24 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Determining program name/number of paramaters from called
> COBOL
> > > program
> > >
> > > Hello,
> > >
> > > I am hoping someone out there can help me with this 'opportunity'.
> > >
> > > In a Z/OS enterprise COBOL environment, I want to be able to retrieve
> the
> > > calling program name and the number of parms passed to the called
> program
> > > from the called program. In other words, program A is executed in my
> > batch
> > > job and it calls program B passing 5 parms in the using statement. I
> want
> > > program B to be able to retrieve the program name for program A as well
> > as
> > > the number of parms that were passed to it.
> > >
> > > I think if I could get to the program stack I could probably figure it
> > out
> > > from there.
> > >
> > > Any assistance that any of you could provide would be greatly
> > appreciated.
> > >
> > > Thanks!
> > >
> > > --
> > > 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
> >
> > --
> > 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
>

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

Re: Determining program name/number of paramaters from called COBOL program

[Mike Hochee]

If you can call a small assembler subroutine from the current COBOL pgm being 
executed (may be possible to do this in COBOL as well), use of the following 
fields should help get you current program name, callers name..., callers name, 
etc..  As mentioned, LE may make a difference, not sure. Anyway... 

Curr TCB addr (PSATOLD), to curr active RB (TCBRBP), to curr CDE (RBCDE), to 
curr pgm name (CDNAME)   (you are at the end of the chain when RBCDE1=0, and 
you may have to clear the high order byte to get a valid compare) 
  
For the name of previous caller(s)... 
Curr TCB addr (PSATOLD), to curr active RB (TCBRBP), to next RB in chain 
(RBLINK), to curr CDE (RBCDE), to pgm name (CDENAME)   

HTH, 
Mike 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Cantrell
Sent: Tuesday, September 22, 2020 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Determining program name/number of paramaters from called COBOL program

Caution! This message was sent from outside your organization.

Hello,

I am hoping someone out there can help me with this 'opportunity'.

In a Z/OS enterprise COBOL environment, I want to be able to retrieve the 
calling program name and the number of parms passed to the called program from 
the called program. In other words, program A is executed in my batch job and 
it calls program B passing 5 parms in the using statement. I want program B to 
be able to retrieve the program name for program A as well as the number of 
parms that were passed to it.

I think if I could get to the program stack I could probably figure it out from 
there.

Any assistance that any of you could provide would be greatly appreciated.

Thanks!

--
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: Determining program name/number of paramaters from called COBOL program

[Seymour J Metz]

If the data are not in the called programs then chasing the save areas won't 
find the data. The basic form of a SAVE is just an STM (24 bit) or similar 
instructions.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Tuesday, September 22, 2020 4:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining program name/number of paramaters from called COBOL 
program

he could work his way back thru the saveareas, no?

Joe

On Tue, Sep 22, 2020 at 3:05 PM Seymour J Metz  wrote:

> Standard linkage conventions don't require branching around an eyecatcher
> or that they eyecatcher be in a standardized format or even include the
> module name. So the question is what special cases does the OP need to
> handle.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Joe Monk 
> Sent: Tuesday, September 22, 2020 4:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining program name/number of paramaters from called
> COBOL program
>
> If it's using standard OS linkage, he could use an assembler routine to do
> a traceback and get some of the items.
>
> The problem will come in if passed by value instead of by reference...
>
> Joe
>
> On Tue, Sep 22, 2020 at 2:58 PM Seymour J Metz  wrote:
>
> > I doubt that it's possible in general, certain special cases are
> possible.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Chris Cantrell 
> > Sent: Tuesday, September 22, 2020 3:24 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Determining program name/number of paramaters from called COBOL
> > program
> >
> > Hello,
> >
> > I am hoping someone out there can help me with this 'opportunity'.
> >
> > In a Z/OS enterprise COBOL environment, I want to be able to retrieve the
> > calling program name and the number of parms passed to the called program
> > from the called program. In other words, program A is executed in my
> batch
> > job and it calls program B passing 5 parms in the using statement. I want
> > program B to be able to retrieve the program name for program A as well
> as
> > the number of parms that were passed to it.
> >
> > I think if I could get to the program stack I could probably figure it
> out
> > from there.
> >
> > Any assistance that any of you could provide would be greatly
> appreciated.
> >
> > Thanks!
> >
> > --
> > 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
>
> --
> 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: Determining program name/number of paramaters from called COBOL program

[Joe Monk]

he could work his way back thru the saveareas, no?

Joe

On Tue, Sep 22, 2020 at 3:05 PM Seymour J Metz  wrote:

> Standard linkage conventions don't require branching around an eyecatcher
> or that they eyecatcher be in a standardized format or even include the
> module name. So the question is what special cases does the OP need to
> handle.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Joe Monk 
> Sent: Tuesday, September 22, 2020 4:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining program name/number of paramaters from called
> COBOL program
>
> If it's using standard OS linkage, he could use an assembler routine to do
> a traceback and get some of the items.
>
> The problem will come in if passed by value instead of by reference...
>
> Joe
>
> On Tue, Sep 22, 2020 at 2:58 PM Seymour J Metz  wrote:
>
> > I doubt that it's possible in general, certain special cases are
> possible.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Chris Cantrell 
> > Sent: Tuesday, September 22, 2020 3:24 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Determining program name/number of paramaters from called COBOL
> > program
> >
> > Hello,
> >
> > I am hoping someone out there can help me with this 'opportunity'.
> >
> > In a Z/OS enterprise COBOL environment, I want to be able to retrieve the
> > calling program name and the number of parms passed to the called program
> > from the called program. In other words, program A is executed in my
> batch
> > job and it calls program B passing 5 parms in the using statement. I want
> > program B to be able to retrieve the program name for program A as well
> as
> > the number of parms that were passed to it.
> >
> > I think if I could get to the program stack I could probably figure it
> out
> > from there.
> >
> > Any assistance that any of you could provide would be greatly
> appreciated.
> >
> > Thanks!
> >
> > --
> > 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
>
> --
> 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

GSE UK Large Systems WG: call for speakers [November 2020]

[Anna Shugol]

Dear all, 

I have a couple of speaker slots available for LSWG stream - if you are 
interested in presenting please get in touch. The conference will be 
virtual of course.

Thanks
--
Best regards,
Anna Shugol
Solutions Engineer | RedHat Synergy | Worldwide IBM Z
mailto:anna.shu...@ibm.com
London, England
+44 7392 199851



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: Determining program name/number of paramaters from called COBOL program

[Seymour J Metz]

Standard linkage conventions don't require branching around an eyecatcher or 
that they eyecatcher be in a standardized format or even include the module 
name. So the question is what special cases does the OP need to handle.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Tuesday, September 22, 2020 4:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining program name/number of paramaters from called COBOL 
program

If it's using standard OS linkage, he could use an assembler routine to do
a traceback and get some of the items.

The problem will come in if passed by value instead of by reference...

Joe

On Tue, Sep 22, 2020 at 2:58 PM Seymour J Metz  wrote:

> I doubt that it's possible in general, certain special cases are possible.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Chris Cantrell 
> Sent: Tuesday, September 22, 2020 3:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Determining program name/number of paramaters from called COBOL
> program
>
> Hello,
>
> I am hoping someone out there can help me with this 'opportunity'.
>
> In a Z/OS enterprise COBOL environment, I want to be able to retrieve the
> calling program name and the number of parms passed to the called program
> from the called program. In other words, program A is executed in my batch
> job and it calls program B passing 5 parms in the using statement. I want
> program B to be able to retrieve the program name for program A as well as
> the number of parms that were passed to it.
>
> I think if I could get to the program stack I could probably figure it out
> from there.
>
> Any assistance that any of you could provide would be greatly appreciated.
>
> Thanks!
>
> --
> 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

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

Re: Determining program name/number of paramaters from called COBOL program

[Joe Monk]

If it's using standard OS linkage, he could use an assembler routine to do
a traceback and get some of the items.

The problem will come in if passed by value instead of by reference...

Joe

On Tue, Sep 22, 2020 at 2:58 PM Seymour J Metz  wrote:

> I doubt that it's possible in general, certain special cases are possible.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Chris Cantrell 
> Sent: Tuesday, September 22, 2020 3:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Determining program name/number of paramaters from called COBOL
> program
>
> Hello,
>
> I am hoping someone out there can help me with this 'opportunity'.
>
> In a Z/OS enterprise COBOL environment, I want to be able to retrieve the
> calling program name and the number of parms passed to the called program
> from the called program. In other words, program A is executed in my batch
> job and it calls program B passing 5 parms in the using statement. I want
> program B to be able to retrieve the program name for program A as well as
> the number of parms that were passed to it.
>
> I think if I could get to the program stack I could probably figure it out
> from there.
>
> Any assistance that any of you could provide would be greatly appreciated.
>
> Thanks!
>
> --
> 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: Determining program name/number of paramaters from called COBOL program

[Seymour J Metz]

I doubt that it's possible in general, certain special cases are possible.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Chris Cantrell 
Sent: Tuesday, September 22, 2020 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Determining program name/number of paramaters from called COBOL program

Hello,

I am hoping someone out there can help me with this 'opportunity'.

In a Z/OS enterprise COBOL environment, I want to be able to retrieve the 
calling program name and the number of parms passed to the called program from 
the called program. In other words, program A is executed in my batch job and 
it calls program B passing 5 parms in the using statement. I want program B to 
be able to retrieve the program name for program A as well as the number of 
parms that were passed to it.

I think if I could get to the program stack I could probably figure it out from 
there.

Any assistance that any of you could provide would be greatly appreciated.

Thanks!

--
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: Determining program name/number of paramaters from called COBOL program

[Joe Monk]

Language Environment or non-LE?

Joe

On Tue, Sep 22, 2020 at 2:24 PM Chris Cantrell <
chris.cantr...@palmettogba.com> wrote:

> Hello,
>
> I am hoping someone out there can help me with this 'opportunity'.
>
> In a Z/OS enterprise COBOL environment, I want to be able to retrieve the
> calling program name and the number of parms passed to the called program
> from the called program. In other words, program A is executed in my batch
> job and it calls program B passing 5 parms in the using statement. I want
> program B to be able to retrieve the program name for program A as well as
> the number of parms that were passed to it.
>
> I think if I could get to the program stack I could probably figure it out
> from there.
>
> Any assistance that any of you could provide would be greatly appreciated.
>
> Thanks!
>
> --
> 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: SORT question: How to both remove records from a file AND write removed records to a 2nd output?

[Sri h Kolusu]

> On the "tagging" that Sri Hari mentioned:
>
> 1) You needn't tag unless you want to - and there will be some occasions
> where you don't want to.

Matrin,

Fully agreed.  I just wanted to show case with IFTHEN it is much easier to
split into multiple files with different conditions.

> Just some thoughts from someone who's loved playing with what DFSORT can
> do but has never actually been a DFSORT developer.


You are always welcome to join DFSORT.


Thanks,
Kolusu


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

Re: Determining program name/number of paramaters from called COBOL program

[Charles Mills]

I think the official, supported answer would be that the calling program should 
pass that information.

With regard to number of parms -- COBOL should have a special register for 
that! -- I suspect you could write an assembler program that you called from 
the called COBOL program, worked its way back through the save area chain, 
found the parms that its caller was called with, and counted them. You might 
have to experiment to determine whether the call was one save area back, two, 
or perhaps more. Hopefully it would be consistent, but see paragraph one above.

The name of the calling program is a little more difficult. What is its "name"? 
The PROGRAM-ID? The PGM= name? What about subprograms and dynamically loaded 
callers?

You can get the PGM= name from the JSCB (again, from an assembler subroutine).

PSATOLD->TCB
TCBJSCB->JSCB
JSCBPGMN is the PGM= name

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Cantrell
Sent: Tuesday, September 22, 2020 12:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Determining program name/number of paramaters from called COBOL program

Hello,

I am hoping someone out there can help me with this 'opportunity'.

In a Z/OS enterprise COBOL environment, I want to be able to retrieve the 
calling program name and the number of parms passed to the called program from 
the called program. In other words, program A is executed in my batch job and 
it calls program B passing 5 parms in the using statement. I want program B to 
be able to retrieve the program name for program A as well as the number of 
parms that were passed to it.

I think if I could get to the program stack I could probably figure it out from 
there.

Any assistance that any of you could provide would be greatly appreciated.

Thanks!

--
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: SORT question: How to both remove records from a file AND write removed records to a 2nd output?

[Paul Gilmartin]

On Tue, 22 Sep 2020 20:08:12 +0100, Martin Packer wrote:
>
>SAVE has, to my mind, been most invaluable. Prior to this you had to
>figure out the boolean complement of the INCLUDE= clause. With more than
>one INCLUDE= clause in a sort it became hairier, requiring De Morgan's
>Law*. :-)  SAVE made this a lot simpler and less error prone.
> 
Yet adding a NOT operator to the grammar (no one has mentioned that
there is one) would relieve programmers of the chore of rewriting complex
Boolean expressions with De Morgan's Law.

>"Card Dealer" not so much.
> 
I don't know "Card Dealer".  Does that amount to having multiple OUTFILs
using different tags?

Thanks,
gil

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

Determining program name/number of paramaters from called COBOL program

[Chris Cantrell]

Hello,

I am hoping someone out there can help me with this 'opportunity'.

In a Z/OS enterprise COBOL environment, I want to be able to retrieve the 
calling program name and the number of parms passed to the called program from 
the called program. In other words, program A is executed in my batch job and 
it calls program B passing 5 parms in the using statement. I want program B to 
be able to retrieve the program name for program A as well as the number of 
parms that were passed to it.

I think if I could get to the program stack I could probably figure it out from 
there.

Any assistance that any of you could provide would be greatly appreciated.

Thanks!

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

Re: SORT question: How to both remove records from a file AND write removed records to a 2nd output?

[Martin Packer]

Back in the mists of time - so I can say it now :-) - Frank Yaeger and I 
were discussing how we might add some things to the first offering of 
OUTFIL in DFSORT that weren't then in Syncsort. We came up with SAVE and 
"Card Dealer".

SAVE has, to my mind, been most invaluable. Prior to this you had to 
figure out the boolean complement of the INCLUDE= clause. With more than 
one INCLUDE= clause in a sort it became hairier, requiring De Morgan's 
Law*. :-)  SAVE made this a lot simpler and less error prone.

"Card Dealer" not so much.

I would expect both implementations - DFSORT and Syncsort - to have had 
these functions since the 1990s and both have gone much further.

On the "tagging" that Sri Hari mentioned:

1) You needn't tag unless you want to - and there will be some occasions 
where you don't want to. One example might be if you've been counting with 
SUM FIELDS= and a binary "ONE" field. You might throw away records where 
the count is less than, say, 100.

2) One other thing you might want to do is to throw away, say, 90% of the 
records on the way in with INCLUDE/OMIT and then divide up the surviving 
records on the way out, using OUTFIL INCLUDE=/OMIT= and SAVE.

Just some thoughts from someone who's loved playing with what DFSORT can 
do but has never actually been a DFSORT developer.

* Augustus De Morgan founded the Maths Department at UCL, where I learnt a 
trick or two. :-)

Cheers, Martin

Martin Packer

Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

Mainframe, Performance, Topics Podcast Series (With Marna Walle): 
https://anchor.fm/marna-walle

Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Sri h Kolusu 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/09/2020 19:24
Subject:[EXTERNAL] Re: SORT question: How to both remove records 
from a file AND write removed records to a 2nd output?
Sent by:IBM Mainframe Discussion List 



> In one pass of an input file is there a way to use SORT to both
> remove identified records from an input file AND write those removed
> records to a second output file?


Peter,

You don't need 2 passes of data, you can tag the records that match your
identification and then use that tag to filter the records on OUTFIL. Some
thing like this

//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD *
ABC  - DROP THIS RECORD
DEF  - PICK THIS RECORD
EFG  - PICK THIS RECORD
XYZ  - DROP THIS RECORD
ZZZ  - DROP THIS RECORD
//PICKREC  DD SYSOUT=*
//DROPREC  DD SYSOUT=*
//SYSINDD *
  OPTION COPY
  INREC IFTHEN=(WHEN=(1,3,SS,EQ,C'DEF,EFG'),
   OVERLAY=(81:C'A'))

  OUTFIL FNAMES=PICKREC,
  INCLUDE=(81,1,CH,EQ,C'A'),
  BUILD=(1,80)

  OUTFIL FNAMES=DROPREC,SAVE,
  BUILD=(1,80)
/*


The PICKREC file will have the following records

DEF  - PICK THIS RECORD
EFG  - PICK THIS RECORD

The DROPREC file will have the following records

ABC  - DROP THIS RECORD
XYZ  - DROP THIS RECORD
ZZZ  - DROP THIS RECORD


For VB files, make sure that you have the Indicator right after the RDW so
that you retain the variable length records as is

Something like this

//SYSINDD *
  OPTION COPY
  INREC IFTHEN=(WHEN=INIT,
 BUILD=(1,4,$ RDW
X,  $ ID TAG
5)),$ DATA AS-IS

IFTHEN=(WHEN=(6,3,SS,EQ,C'DEF,EFG'),
   OVERLAY=(05:C'A'))

  OUTFIL FNAMES=PICKREC,
  INCLUDE=(05,1,CH,EQ,C'A'),
BUILD=(1,04,$ RDW
   6)   $ DATA AS-IS

  OUTFIL FNAMES=DROPREC,SAVE,
BUILD=(1,04,$ RDW
   6)   $ DATA AS-IS
/*


Fruther if you have any questions please let me know

Thanks,
 Kolusu
DFSORT Development
IBM Corporation

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: BOF on COBOL and the systems programmer at SHARE

[Richards, Robert B.]

Not to mention all sessions are recorded! 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Tuesday, September 22, 2020 2:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BOF on COBOL and the systems programmer at SHARE

No good deed goes unpunished.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, September 22, 2020 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BOF on COBOL and the systems programmer at SHARE

On Tue, 22 Sep 2020 12:36:10 -0300, Clark Morris wrote:

>I am giving a BOF on COBOL and the systems programmer on Thursday, 
>September 24 in the last session period - 16:15 Eastern time zone,
>15:15 Central time zone, 14:15, Mountain time zone, 13:15 Pacific time, 
>17:15 Atlantic time zone in Canada and 17:45 in Newfoundland.
> 
Couldn't you simply say GMT?  What time in Arizona?  Hawaii?
The Navajo Nation?  ...

--
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: SORT question: How to both remove records from a file AND write removed records to a 2nd output?

[Farley, Peter x23353]

Thanks Sri, that is just what I need.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Tuesday, September 22, 2020 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT question: How to both remove records from a file AND write 
removed records to a 2nd output?

> In one pass of an input file is there a way to use SORT to both remove 
> identified records from an input file AND write those removed records 
> to a second output file?


Peter,

You don't need 2 passes of data, you can tag the records that match your 
identification and then use that tag to filter the records on OUTFIL. Some 
thing like this

//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD *
ABC  - DROP THIS RECORD
DEF  - PICK THIS RECORD
EFG  - PICK THIS RECORD
XYZ  - DROP THIS RECORD
ZZZ  - DROP THIS RECORD
//PICKREC  DD SYSOUT=*
//DROPREC  DD SYSOUT=*
//SYSINDD *
  OPTION COPY
  INREC IFTHEN=(WHEN=(1,3,SS,EQ,C'DEF,EFG'),
   OVERLAY=(81:C'A'))

  OUTFIL FNAMES=PICKREC,
  INCLUDE=(81,1,CH,EQ,C'A'),
  BUILD=(1,80)

  OUTFIL FNAMES=DROPREC,SAVE,
  BUILD=(1,80)
/*


The PICKREC file will have the following records

DEF  - PICK THIS RECORD
EFG  - PICK THIS RECORD

The DROPREC file will have the following records

ABC  - DROP THIS RECORD
XYZ  - DROP THIS RECORD
ZZZ  - DROP THIS RECORD


For VB files, make sure that you have the Indicator right after the RDW so that 
you retain the variable length records as is

Something like this

//SYSINDD *
  OPTION COPY
  INREC IFTHEN=(WHEN=INIT,
 BUILD=(1,4,$ RDW
X,  $ ID TAG
5)),$ DATA AS-IS

IFTHEN=(WHEN=(6,3,SS,EQ,C'DEF,EFG'),
   OVERLAY=(05:C'A'))

  OUTFIL FNAMES=PICKREC,
  INCLUDE=(05,1,CH,EQ,C'A'),
BUILD=(1,04,$ RDW
   6)   $ DATA AS-IS

  OUTFIL FNAMES=DROPREC,SAVE,
BUILD=(1,04,$ RDW
   6)   $ DATA AS-IS
/*

--

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

Re: Any IMS group?

[Lizette Koehler]

There is a list for almost all activities on the Mainframe.  A internet search 
on IMS LIST would pull it up 

IMS http://imslistserv.bmc.com/scripts/wa-BMC.exe?A0=ims-l

Lizette 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
johnnydeep san
Sent: Tuesday, September 22, 2020 7:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Any IMS group?

Hi,

Do we have any groups for the IMS  group to discuss some Admin stuff? .

Regards,
JD

--
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: PDS86 SHR?

[Binyamin Dissen]

On Tue, 22 Sep 2020 12:37:46 -0500 Skippy the Ancient 
wrote:

:>There is a dataset missing a member.  PDS86 won't play with it because it 
allocated to an STC.
:>Is it possible to invoke PDS86 so it doesn't allocate the DSN as OLD?

Use the SHR keyword?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: SORT question: How to both remove records from a file AND write removed records to a 2nd output?

[Sri h Kolusu]

> In one pass of an input file is there a way to use SORT to both
> remove identified records from an input file AND write those removed
> records to a second output file?


Peter,

You don't need 2 passes of data, you can tag the records that match your
identification and then use that tag to filter the records on OUTFIL. Some
thing like this

//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD *
ABC  - DROP THIS RECORD
DEF  - PICK THIS RECORD
EFG  - PICK THIS RECORD
XYZ  - DROP THIS RECORD
ZZZ  - DROP THIS RECORD
//PICKREC  DD SYSOUT=*
//DROPREC  DD SYSOUT=*
//SYSINDD *
  OPTION COPY
  INREC IFTHEN=(WHEN=(1,3,SS,EQ,C'DEF,EFG'),
   OVERLAY=(81:C'A'))

  OUTFIL FNAMES=PICKREC,
  INCLUDE=(81,1,CH,EQ,C'A'),
  BUILD=(1,80)

  OUTFIL FNAMES=DROPREC,SAVE,
  BUILD=(1,80)
/*


The PICKREC file will have the following records

DEF  - PICK THIS RECORD
EFG  - PICK THIS RECORD

The DROPREC file will have the following records

ABC  - DROP THIS RECORD
XYZ  - DROP THIS RECORD
ZZZ  - DROP THIS RECORD


For VB files, make sure that you have the Indicator right after the RDW so
that you retain the variable length records as is

Something like this

//SYSINDD *
  OPTION COPY
  INREC IFTHEN=(WHEN=INIT,
 BUILD=(1,4,$ RDW
X,  $ ID TAG
5)),$ DATA AS-IS

IFTHEN=(WHEN=(6,3,SS,EQ,C'DEF,EFG'),
   OVERLAY=(05:C'A'))

  OUTFIL FNAMES=PICKREC,
  INCLUDE=(05,1,CH,EQ,C'A'),
BUILD=(1,04,$ RDW
   6)   $ DATA AS-IS

  OUTFIL FNAMES=DROPREC,SAVE,
BUILD=(1,04,$ RDW
   6)   $ DATA AS-IS
/*


Fruther if you have any questions please let me know

Thanks,
 Kolusu
DFSORT Development
IBM Corporation

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

Re: BOF on COBOL and the systems programmer at SHARE

[Charles Mills]

No good deed goes unpunished.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, September 22, 2020 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BOF on COBOL and the systems programmer at SHARE

On Tue, 22 Sep 2020 12:36:10 -0300, Clark Morris wrote:

>I am giving a BOF on COBOL and the systems programmer on Thursday,
>September 24 in the last session period - 16:15 Eastern time zone,
>15:15 Central time zone, 14:15, Mountain time zone, 13:15 Pacific
>time, 17:15 Atlantic time zone in Canada and 17:45 in Newfoundland.
> 
Couldn't you simply say GMT?  What time in Arizona?  Hawaii?
The Navajo Nation?  ...

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

Re: SORT question: How to both remove records from a file AND write removed records to a 2nd output?

[Farley, Peter x23353]

Thanks Max, that would seem to be the way.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Massimo Biancucci
Sent: Tuesday, September 22, 2020 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT question: How to both remove records from a file AND write 
removed records to a 2nd output?

Peter,

look at OUTFIL syntax and SAVE keyword.

Regards.
Max

> In one pass of an input file is there a way to use SORT to both remove 
> identified records from an input file AND write those removed records 
> to a second output file?
>
> I know I can run two passes of the input using INCLUDE in pass 1 to 
> select just the records to be removed and a second pass using OMIT to 
> take them out, but can it be done in one pass?
>
> Peter
--

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

Re: PDS86 SHR?

[Paul Gilmartin]

On Tue, 22 Sep 2020 12:37:46 -0500, Skippy the Ancient wrote:

>There is a dataset missing a member.  PDS86 won't play with it because it 
>allocated to an STC.
>Is it possible to invoke PDS86 so it doesn't allocate the DSN as OLD?
> 
Might there be an option to use ISPF serialization conventions, allocating
SHR with qname SYSDSN and momentarily EXC with qname SPFEDIT?
 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.f54pc00/isppcmmnamen.htm

-- gil

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

Re: SORT question: How to both remove records from a file AND write removed records to a 2nd output?

[Massimo Biancucci]

Peter,

look at OUTFIL syntax and SAVE keyword.

Regards.
Max


Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno mar 22 set 2020 alle ore 19:22 Farley, Peter x23353 <
031df298a9da-dmarc-requ...@listserv.ua.edu> ha scritto:

> In one pass of an input file is there a way to use SORT to both remove
> identified records from an input file AND write those removed records to a
> second output file?
>
> I know I can run two passes of the input using INCLUDE in pass 1 to select
> just the records to be removed and a second pass using OMIT to take them
> out, but can it be done in one pass?
>
> Peter
>
> 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

Re: Caution: "Hacked" email caused the distribution of a potentially harmful attachment

[Seymour J Metz]

Many of us receive legitimate e-mail from unknown senders, or from known 
senders with new addresses.

The e-mail addresses in headers are not trustworthy. Digital signatures are 
only trustworthy if you got the public key from a trusted source.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of CM 
Poncelet 
Sent: Monday, September 21, 2020 10:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Caution: "Hacked" email caused the distribution of a potentially 
harmful attachment

FWIW

(a) Begin by assuming that *all* received emails are spam/scam (and
define this as the bottom line catch-all message filter) *unless* a
higher up message filter recognizes both the sender(s)'s and the 'to'
recipient's addresses as valid.
(b) The sender's original email address can be found towards the end in
the message headers, as in the "received from ... for ..." message
header line.
(c) Spam/scam emails can be sent to
https://www.spamcop.net/mcgi?action=loginform for verification, if need be.

The 'trick' to get around spammers/scammers is to use message filters,
with the bottom line catch-all filter saying something like "if the
subject does not contain  *and*
the sender is not @ then save
the email in the trash/delete folder" - which then ensures that the
email is never saved in the "Inbox" folder.

A more skilful 'trick' is to have many different email IDs and give out
a different email ID to every company, individual etc. (and keep a
record of which email ID was given to whom) - so that, if a spammer or
scammer gets hold of it, it can be deleted and a replacement new email
ID can be created ... and then also determine from whom the
spammer/scammer harvested the old and now deleted email ID. That kills
off spammers and scammers, because any further emails sent to the old
email ID just bounce as "undeliverable" and they cannot guess what the
new email ID is. But that requires owning one or more domain names and
being able to create/delete email IDs associated with it/them. (I
have/use more than 200 email IDs across more than 30 domain names.)

HTH.

Cheers, Chris Poncelet (retired sysprog)



On 22/09/2020 00:04, Bob Bridges wrote:
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jesse 1 Robinson
> Sent: Monday, September 21, 2020 17:08
>
> JR> The idea of deliberately dumbing down language in spam is preposterous. 
> First of all I don't understand the purported logic of it.
>
> BB> Radoslaw's logic seemed clear to me, but when I set out to spell it out 
> for you, I began to wonder whether I'd mistaken it.  He wrote "a method to 
> filter out bright people and leave only the fools", which I interpreted this 
> way:  Intelligent people (according to Radoslaw) are less likely to produce 
> profit for the scammer, in the long run.  If the scam is written badly, an 
> intelligent person is more likely to throw it out, and thus less likely to 
> waste the scammer's time with replies that will in the end lead nowhere.  
> Fools, meanwhile, will not notice (or notice less) the atrocious writing, and 
> thus be more likely to proceed.
>
> I'll leave it to him to say whether I read him correctly.  But ~if~ that is 
> indeed the scammer's motive for writing badly, I think the scammer isn't 
> thinking very clearly.
>
> The next part of your comment I think is just a confusion about who said 
> what.  I said Nigerians are mostly capable of better English than I see in 
> "Nigerian old ministers' " emails, but that's just a side comment, not part 
> of Radoslaw's reasoning.
>
> JR> More important, while English is an official language in Nigeria, it is 
> no one's mother tongue. It's learned, mostly in school, to whatever 
> proficiency the learner can achieve. The average spammer has probably never 
> stepped inside university. Even secondary school certification is improbable. 
> Add to that the 'dialectical' difference between Nigerian and American 
> English makes it unlikely that the most fluent spammer could write something 
> of undetectable of origin.
>
> BB> I don't buy that last part.  I have no idea how many spammers have been 
> to University, or secondary school, but they can't ~all~ be illiterate and 
> therefore it's not unlikely - just the reverse - that some of them will be 
> able to compose a grammatically correct email.  No one said anything about 
> "undetectable"; for verisimilitude you'd want ~some~ degree of "foreign-ness".
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* ...in your bedchamber do not curse a king, and in your sleeping rooms do 
> not curse a rich man, for a bird of the heavens will carry the sound, and the 
> winged creature will make the matter known.  -Ecclesiastes 10:20 */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Bob Bridges
> Sent: Monday, September 21, 

PDS86 SHR?

[Skippy the Ancient]

There is a dataset missing a member.  PDS86 won't play with it because it 
allocated to an STC.
Is it possible to invoke PDS86 so it doesn't allocate the DSN as OLD?

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

Re: [External] BOF on COBOL and the systems programmer at SHARE

[Pommier, Rex]

Thanks, Clark, 

Hoping to see you at 15:15 Central time on Thursday.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Clark Morris
Sent: Tuesday, September 22, 2020 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] BOF on COBOL and the systems programmer at SHARE

I am giving a BOF on COBOL and the systems programmer on Thursday, September 24 
in the last session period - 16:15 Eastern time zone,
15:15 Central time zone, 14:15, Mountain time zone, 13:15 Pacific time, 17:15 
Atlantic time zone in Canada and 17:45 in Newfoundland.

There will be a 10 minute introduction (I timed it). It covers items in the 
COBOL standard not in Enterprise COBOL that might be of use to your shop, 
facilities in Enterprise COBOL that your shop may have overlooked, caution on 
setting defaults, and why standards should be reviewed with each new release.  
The rest of the session will be devoted to whatever the attendees want to 
discuss and explore.

I have used COBOL to get information from SMF records because it was easier 
than assembler and my shop didn't have SAS.  I have been responsible for review 
and recommendation of COBOl and LE defaults in
2 different shops.  I was active in SHARE starting in 1977 through 2002.

Clark Morris 

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

SORT question: How to both remove records from a file AND write removed records to a 2nd output?

[Farley, Peter x23353]

In one pass of an input file is there a way to use SORT to both remove 
identified records from an input file AND write those removed records to a 
second output file?

I know I can run two passes of the input using INCLUDE in pass 1 to select just 
the records to be removed and a second pass using OMIT to take them out, but 
can it be done in one pass?

Peter

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

Re: AT-TLS issues with FTP and SSH

[Lionel B Dyck]

Found issue with SSH - I had created (mkdir) the .ssh directory so it had
the default permissions.  Should have let ssh-keygen create it.

Tried adding logging to pagent for ftp - overloaded with messages and
reading them now.

Thank you


Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Mike Hochee
Sent: Tuesday, September 22, 2020 11:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AT-TLS issues with FTP and SSH

Regarding the AT-TLS issue, your pagent is likely encountering a problem in
the FTP section (of course!).  Look at the log it generates, and if you
don't have one, add the logging option to the pagent start command. If I
remember correctly, there's also a verbose setting. I found the logs to be
extremely useful.   

HTH,
Mike 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lionel B Dyck
Sent: Tuesday, September 22, 2020 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AT-TLS issues with FTP and SSH

Caution! This message was sent from outside your organization.

We just enabled AT-TLS (PAGENT) on a test LPAR and immediately ran into two
issues:

1. The FTP Client ceased to work (until we commented the FTP section in the
pagent_TTLS.conf file)
a. No issues doing an FTP into this LPAR.
2. Git stopped working due to SSH.

A simple test is:ssh mailto:g...@github.com

And for that I'm getting: FOTS3322 Passwords may not be entered from 3270
terminals

If we stop PAGENT then everything works.

Can anyone offer any pointers/tips/solutions to either of these problems?

Thanks in advance.


Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

--
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: AT-TLS issues with FTP and SSH

[Mike Hochee]

Regarding the AT-TLS issue, your pagent is likely encountering a problem in the 
FTP section (of course!).  Look at the log it generates, and if you don't have 
one, add the logging option to the pagent start command. If I remember 
correctly, there's also a verbose setting. I found the logs to be extremely 
useful.   

HTH, 
Mike 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lionel B Dyck
Sent: Tuesday, September 22, 2020 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AT-TLS issues with FTP and SSH

Caution! This message was sent from outside your organization.

We just enabled AT-TLS (PAGENT) on a test LPAR and immediately ran into two
issues:

1. The FTP Client ceased to work (until we commented the FTP section in the 
pagent_TTLS.conf file)
a. No issues doing an FTP into this LPAR.
2. Git stopped working due to SSH.

A simple test is:ssh mailto:g...@github.com

And for that I'm getting: FOTS3322 Passwords may not be entered from 3270 
terminals

If we stop PAGENT then everything works.

Can anyone offer any pointers/tips/solutions to either of these problems?

Thanks in advance.


Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

--
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: BOF on COBOL and the systems programmer at SHARE

[Paul Gilmartin]

On Tue, 22 Sep 2020 12:36:10 -0300, Clark Morris wrote:

>I am giving a BOF on COBOL and the systems programmer on Thursday,
>September 24 in the last session period - 16:15 Eastern time zone,
>15:15 Central time zone, 14:15, Mountain time zone, 13:15 Pacific
>time, 17:15 Atlantic time zone in Canada and 17:45 in Newfoundland.
> 
Couldn't you simply say GMT?  What time in Arizona?  Hawaii?
The Navajo Nation?  ...

-- gil

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

Re: STIMERM SVCE

[Pierre Fichaud]

The STIMERM is in my code.
The FRR is inside IEEMB830,08/31/16,UA82681 at +9D4.

Regards, Pierre.

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

Re: AT-TLS issues with FTP and SSH

[Paul Gilmartin]

On Tue, 22 Sep 2020 10:07:57 -0500, Lionel B Dyck wrote:
>
>And for that I�m getting: FOTS3322 Passwords may not be entered from 3270
>terminals  
> 
They're giving you a hint.  Eschew 3270; don't be a masochist.

Years ago, I discovered that if I start "script" under 3270 OMVS, then
I can enter passwords.  Evidently script masked the 3270-ness.  I don't
know whether IBM has declared that a weakness and reinforced it.

I did some tests.  In a script I issued "stty -echo"; prompted for a
string; "stty echo".  In a C program, I used tcsetattr([~ECHO]) to
disable echoing; read a string; and restored echoing.

In both cases, the password was hidden in an ssh session but displayed
momentarily in a 3270 session.

I went to SR with both problems.  I didn't mention my "script" hack lest 
they break it.  They fixed stty somehow but chose to leave fcntl() broken.
Go figger.

-- gil

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

Re: Any IMS group?

[ITschak Mugzach]

You better ask here. I am registered to the IMS group but haven't got any
email for a long time now.

ITschak

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM comming son  *




On Tue, Sep 22, 2020 at 6:51 PM Itschak Mugzach 
wrote:

> You better ask here. I am registered to the IMS group but haven't got any
> email for a long time now.
>
> ITschak
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS,
> zLinux and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*
>
>
>
>
>
> On Tue, Sep 22, 2020 at 5:59 PM johnnydeep san 
> wrote:
>
>> Hi,
>>
>> Do we have any groups for the IMS  group to discuss some Admin stuff? .
>>
>> Regards,
>> JD
>>
>> --
>> 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

BOF on COBOL and the systems programmer at SHARE

[Clark Morris]

I am giving a BOF on COBOL and the systems programmer on Thursday,
September 24 in the last session period - 16:15 Eastern time zone,
15:15 Central time zone, 14:15, Mountain time zone, 13:15 Pacific
time, 17:15 Atlantic time zone in Canada and 17:45 in Newfoundland.

There will be a 10 minute introduction (I timed it). It covers items
in the COBOL standard not in Enterprise COBOL that might be of use to
your shop, facilities in Enterprise COBOL that your shop may have
overlooked, caution on setting defaults, and why standards should be
reviewed with each new release.  The rest of the session will be
devoted to whatever the attendees want to discuss and explore.

I have used COBOL to get information from SMF records because it was
easier than assembler and my shop didn't have SAS.  I have been
responsible for review and recommendation of COBOl and LE defaults in
2 different shops.  I was active in SHARE starting in 1977 through
2002.

Clark Morris 

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

Re: Caution: "Hacked" email caused the distribution of a potentially harmful attachment

[Seymour J Metz]

First, the Received: fields contain domain names and IP addresses that depend 
only on envelopes and connecting IP addresses. You should rely on those that 
came from nodes you control or trust; anything beyond that is suspect.

There are various authentication protocols, e.g., SPF (acronym overload), but 
those are only as good as thercertificate owner. That is, you can check with 
the CA that foo owns bar, but not whether foo is a criminal or legitimate.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Tuesday, September 22, 2020 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Caution: "Hacked" email caused the distribution of a potentially 
harmful attachment

I'm pretty sure that in the bad old days, even the headers could not accurately 
reflect the sender.  You could tell what ~server~ the email came from, but the 
email address depended entirely on the From label that every email client 
attaches manually, and which isn't necessarily truthful.

I put this in the past tense not because I believe it's no longer true, but 
because it ~might~ no longer be true.  I know a lot of the major domains are 
adding various headers that purport to guarantee at least that the email came 
from a subscriber at the originating domain.  I don't know how advanced those 
headers are these days.  But until Chris posted the below, I would have said 
you still can't be sure of the sender's email address by looking at the headers.

The headers that came with Chris' email, by the way, are much longer than I'm 
used to seeing.  Is this normal, these days, or is it a feature of IBM-MAIN?  I 
think what I'm seeing is a series of authentication methods as it's passed from 
one server to the next along what I think is called the "backbone": ARC, 
IronPort, and something called TMASE.

(I hope this doesn't break the LISTSERV's filters.)

Delivered-To: robhbrid...@gmail.com
Received: by 2002:adf:f447:0:0:0:0:0 with SMTP id f7csp3851648wrp;
Mon, 21 Sep 2020 19:18:42 -0700 (PDT)
X-Google-Smtp-Source: 
ABdhPJyZYVYvh3cQWqrXkErWaQ9fj0W+BvZi9Nn3OIAhxJo/3CruwF8hoeAX5Oz2VcYZ5dXeWd3e
X-Received: by 2002:a25:4dc3:: with SMTP id a186mr3921730ybb.250.1600741122602;
Mon, 21 Sep 2020 19:18:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1600741122; cv=none;
d=google.com; s=arc-20160816;
b=B58897TXTtvQJ7t1gnHyrcV+cq3LL+jDEM9oArNxwngd5gxmJmVU8iQWMRfzwzIErF
 171T/6dYrx3amczVIU4+RYVmvhPiw4ciJWp6wEkjj4Crj2Idy3h02jmoPxSI6bfpfSYx
 FqaUjP7LwKQ/2TClTi+oAhk19o5H/73ukJTA5+mhsv9CBSm/9aAimG18O14JDpzlgKJO
 CZwngYjwGO/+cJ8VP1MfmKYwOC+Gk1v7+iJLbovbbXQB5yF5tziBBYUjFm2ZJcNDe6zR
 gPstA7GqeqHoI7Q/YvKuVuDqWI45gSXg1uBZwik+4sYFnPucdPQ9J9gAOZ7Q4+7l7syN
 2g6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 
s=arc-20160816;
h=list-archive:list-owner:list-subscribe:list-unsubscribe:list-help
 :precedence:in-reply-to:to:subject:organization:from:sender:reply-to
 :date:newsgroups:message-id:content-language
 :content-transfer-encoding:mime-version:user-agent:references
 :ironport-phdr:dkim-signature;
bh=xak+K7z8G4pm5Gldpny1Rz595iMZvkPotRV2fRPSWh4=;
b=N/3iP2pjAMuhJ3ys6eeEachah/tZmrbzUtQlSghrMQ0SAMkmGZruV01BUBVJhJwK/1
 Q38yPpfJg+QbzHYPu080i4V4MZNYOWPjTNwZJ/f4rGo+HwGPrRzPY5ZBJ6GnYkgIgCx1
 zYENntXTcedNtOC3TS57zGYck/l4DmaNoHpmfyMSdfIyOx3ian0dIC5f7ny1b14ZC6Eg
 9fp07gi9ViNNgy5wyNC+KpxHpsK3m2SU1E8dEfDYBIaHLZZERwcy0fjM9mfyVCf61M8a
 FsFvsqFOLvmk1W4aYLnXxwMC3Uo7oyUNythENV/zL7mweFg5njPKOeHNOXA3+H5PlSHJ
 j6rQ==
ARC-Authentication-Results: i=1; mx.google.com;
   dkim=pass (test mode) header.i=@UA.EDU header.s=LISTSERV01 
header.b=hoKgtLn3;
   spf=pass (google.com: domain of owner-ibm-m...@listserv.ua.edu 
designates 130.160.0.25 as permitted sender) 
smtp.mailfrom=owner-ibm-m...@listserv.ua.edu
Return-Path: 
Received: from lsvmail01.ua.edu (lsvmail01.ua.edu. [130.160.0.25])
by mx.google.com with ESMTPS id m18si15161936ybp.129.2020.09.21.19.18.41
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Mon, 21 Sep 2020 19:18:42 -0700 (PDT)
Received-SPF: pass (google.com: domain of owner-ibm-m...@listserv.ua.edu 
designates 130.160.0.25 as permitted sender) client-ip=130.160.0.25;
Authentication-Results: mx.google.com;
   dkim=pass (test mode) header.i=@UA.EDU header.s=LISTSERV01 
header.b=hoKgtLn3;
   spf=pass (google.com: domain of owner-ibm-m...@listserv.ua.edu 
designates 130.160.0.25 as permitted sender) 
smtp.mailfrom=owner-ibm-m...@listserv.ua.edu
Received: from listserv01.ua.edu (listserv01.ua.edu [10.8.81.163])
by lsvmail01.ua.edu (Postfix) with ESMTP id 9EF7C2695E9;
Mon, 21 Sep 2020 21:18:24 -0500 (CDT)
Received: from listserv01 (localhost [127.0.0.1])
by listserv01.ua.edu (Postfix) with 

Re: STIMERM SVCE

[Peter Relson]

As asked, 

What code owns the FRR? 
*RCVY  FRR  070C 8465F9D4  
What is at 465F9D4?

To me, the most plausible of unlikely scenarios is that something you 
called (at some point via PC), in key 0 supervisor state, set an EUT FRR.
And then it issued a PR to return to you, in your key and state, without 
having deleted the FRR, so now you are running but there is an FRR, so 
your SVC encounters that and gets 0F8-14.

Thus this is not your error, but is something wrong with the authorized 
code failing to delete the FRR.

Perhaps report this to the Dallas folks according to whatever procedures 
are in place.

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

Re: DB2 ERLY code copied in while DB2 is up

[Chris Hoelscher]

I am reasonably certain that 
*ssid REFRESH DB2,EARLY  
Must occur with DB2 down

Else you receive

DSNY003I  *DBT3 SUBSYSTEM IS ALREADY ACTIVE  
DSN9023I  *DBT3 DSNYSCMD 'REFRESH DB2' ABNORMAL COMPLETION   


Chris Hoelscher
Lead Sys DBA 
IBM Global Technical Services on assignmemt to Humana Inc.
T 502.476.2538  or 502.407.7266

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Tuesday, September 22, 2020 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] DB2 ERLY code copied in while DB2 is up

[External Email: Use caution with links and attachments]


I need to move in new DB2 ERLY code. My question is, can I copy in the ERLY 
while DB2 is up. Then after a normally scheduled IPL start DB2? Or does DB2 
need to be down in order to copy in the new ERLY code?
thanks
Bill

--
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, ancestry, 
age, disability, sex,
marital status, gender, sexual orientation, gender identity, or religion. 
Humana Inc. and its subsidiaries do not
exclude people or treat them differently because of race, color, national 
origin, ancestry, age,
disability, sex, marital status, gender, sexual orientation, gender identity, 
or religion.

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

AT-TLS issues with FTP and SSH

[Lionel B Dyck]

We just enabled AT-TLS (PAGENT) on a test LPAR and immediately ran into two
issues:

1. The FTP Client ceased to work (until we commented the FTP section in the
pagent_TTLS.conf file)
a. No issues doing an FTP into this LPAR.
2. Git stopped working due to SSH.

A simple test is:ssh mailto:g...@github.com

And for that I’m getting: FOTS3322 Passwords may not be entered from 3270
terminals  

If we stop PAGENT then everything works.

Can anyone offer any pointers/tips/solutions to either of these problems?

Thanks in advance.


Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

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

Any IMS group?

[johnnydeep san]

Hi,

Do we have any groups for the IMS  group to discuss some Admin stuff? .

Regards,
JD

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

Re: DB2 ERLY code copied in while DB2 is up

[Mark Jacobs]

If you mean copy it into the dataset where it's loaded from when it's needed, 
then yes you can.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, September 22, 2020 10:33 AM, Bill Giannelli 
 wrote:

> I need to move in new DB2 ERLY code. My question is, can I copy in the ERLY 
> while DB2 is up. Then after a normally scheduled IPL start DB2? Or does DB2 
> need to be down in order to copy in the new ERLY code?
> thanks
> Bill
>
> ---
>
> 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

DB2 ERLY code copied in while DB2 is up

[Bill Giannelli]

I need to move in new DB2 ERLY code. My question is, can I copy in the ERLY 
while DB2 is up. Then after a normally scheduled IPL start DB2? Or does DB2 
need to be down in order to copy in the new ERLY code?
thanks
Bill

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

Re: Caution: "Hacked" email caused the distribution of a potentially harmful attachment

[Bob Bridges]

I'm pretty sure that in the bad old days, even the headers could not accurately 
reflect the sender.  You could tell what ~server~ the email came from, but the 
email address depended entirely on the From label that every email client 
attaches manually, and which isn't necessarily truthful.

I put this in the past tense not because I believe it's no longer true, but 
because it ~might~ no longer be true.  I know a lot of the major domains are 
adding various headers that purport to guarantee at least that the email came 
from a subscriber at the originating domain.  I don't know how advanced those 
headers are these days.  But until Chris posted the below, I would have said 
you still can't be sure of the sender's email address by looking at the headers.

The headers that came with Chris' email, by the way, are much longer than I'm 
used to seeing.  Is this normal, these days, or is it a feature of IBM-MAIN?  I 
think what I'm seeing is a series of authentication methods as it's passed from 
one server to the next along what I think is called the "backbone": ARC, 
IronPort, and something called TMASE.

(I hope this doesn't break the LISTSERV's filters.)

Delivered-To: robhbrid...@gmail.com
Received: by 2002:adf:f447:0:0:0:0:0 with SMTP id f7csp3851648wrp;
Mon, 21 Sep 2020 19:18:42 -0700 (PDT)
X-Google-Smtp-Source: 
ABdhPJyZYVYvh3cQWqrXkErWaQ9fj0W+BvZi9Nn3OIAhxJo/3CruwF8hoeAX5Oz2VcYZ5dXeWd3e
X-Received: by 2002:a25:4dc3:: with SMTP id a186mr3921730ybb.250.1600741122602;
Mon, 21 Sep 2020 19:18:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1600741122; cv=none;
d=google.com; s=arc-20160816;
b=B58897TXTtvQJ7t1gnHyrcV+cq3LL+jDEM9oArNxwngd5gxmJmVU8iQWMRfzwzIErF
 171T/6dYrx3amczVIU4+RYVmvhPiw4ciJWp6wEkjj4Crj2Idy3h02jmoPxSI6bfpfSYx
 FqaUjP7LwKQ/2TClTi+oAhk19o5H/73ukJTA5+mhsv9CBSm/9aAimG18O14JDpzlgKJO
 CZwngYjwGO/+cJ8VP1MfmKYwOC+Gk1v7+iJLbovbbXQB5yF5tziBBYUjFm2ZJcNDe6zR
 gPstA7GqeqHoI7Q/YvKuVuDqWI45gSXg1uBZwik+4sYFnPucdPQ9J9gAOZ7Q4+7l7syN
 2g6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 
s=arc-20160816;
h=list-archive:list-owner:list-subscribe:list-unsubscribe:list-help
 :precedence:in-reply-to:to:subject:organization:from:sender:reply-to
 :date:newsgroups:message-id:content-language
 :content-transfer-encoding:mime-version:user-agent:references
 :ironport-phdr:dkim-signature;
bh=xak+K7z8G4pm5Gldpny1Rz595iMZvkPotRV2fRPSWh4=;
b=N/3iP2pjAMuhJ3ys6eeEachah/tZmrbzUtQlSghrMQ0SAMkmGZruV01BUBVJhJwK/1
 Q38yPpfJg+QbzHYPu080i4V4MZNYOWPjTNwZJ/f4rGo+HwGPrRzPY5ZBJ6GnYkgIgCx1
 zYENntXTcedNtOC3TS57zGYck/l4DmaNoHpmfyMSdfIyOx3ian0dIC5f7ny1b14ZC6Eg
 9fp07gi9ViNNgy5wyNC+KpxHpsK3m2SU1E8dEfDYBIaHLZZERwcy0fjM9mfyVCf61M8a
 FsFvsqFOLvmk1W4aYLnXxwMC3Uo7oyUNythENV/zL7mweFg5njPKOeHNOXA3+H5PlSHJ
 j6rQ==
ARC-Authentication-Results: i=1; mx.google.com;
   dkim=pass (test mode) header.i=@UA.EDU header.s=LISTSERV01 
header.b=hoKgtLn3;
   spf=pass (google.com: domain of owner-ibm-m...@listserv.ua.edu 
designates 130.160.0.25 as permitted sender) 
smtp.mailfrom=owner-ibm-m...@listserv.ua.edu
Return-Path: 
Received: from lsvmail01.ua.edu (lsvmail01.ua.edu. [130.160.0.25])
by mx.google.com with ESMTPS id m18si15161936ybp.129.2020.09.21.19.18.41
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Mon, 21 Sep 2020 19:18:42 -0700 (PDT)
Received-SPF: pass (google.com: domain of owner-ibm-m...@listserv.ua.edu 
designates 130.160.0.25 as permitted sender) client-ip=130.160.0.25;
Authentication-Results: mx.google.com;
   dkim=pass (test mode) header.i=@UA.EDU header.s=LISTSERV01 
header.b=hoKgtLn3;
   spf=pass (google.com: domain of owner-ibm-m...@listserv.ua.edu 
designates 130.160.0.25 as permitted sender) 
smtp.mailfrom=owner-ibm-m...@listserv.ua.edu
Received: from listserv01.ua.edu (listserv01.ua.edu [10.8.81.163])
by lsvmail01.ua.edu (Postfix) with ESMTP id 9EF7C2695E9;
Mon, 21 Sep 2020 21:18:24 -0500 (CDT)
Received: from listserv01 (localhost [127.0.0.1])
by listserv01.ua.edu (Postfix) with ESMTP id 3FD8C270077;
Mon, 21 Sep 2020 21:18:24 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; d=UA.EDU; s=LISTSERV01; c=relaxed/relaxed; 
bh=xak+K7z8G4pm5Gldpny1Rz595iMZvkPotRV2fRPSWh4=; i=@LISTSERV.UA.EDU;
 
h=Received-SPF:IronPort-PHdr:References:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Language:Message-ID:Newsgroups:Date:Reply-To:Sender:From:Organization:Subject:To:In-Reply-To:List-Help:List-Unsubscribe:List-Subscribe:List-Owner:List-Archive;
 
b=hoKgtLn3w9W92V9bTKa6UNpuoBFZaitRofoSTpcb5pG+uPHaMDDYxt46yDCJr8Me9e6ms8Y4R46rar4HfwNPpwpnD1Dnb66cHye0twKDs517DlVZ8XKV5WnVD/FFabttLyA53JxrBDRLngQ9zjpwU9rmFtm25ltySVYKYz8yJsA=
Received: by LISTSERV.UA.EDU (LISTSERV-TCP/IP release 16.0) with spool id 29526
  for IBM-MAIN@LISTSERV.UA.EDU; Mon, 21 Sep 

Re: JCL examination prior to execution

[Mark Jacobs]

There's no production on the mainframe, just software development. Also no 
change control to speak of for environmental changes like this. Right now it's 
just wasted system resources to generate and save these dumps that have no 
value and will never be used by the developers.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, September 22, 2020 10:03 AM, Seymour J Metz  wrote:

> Well, you could certainly catch it in a JES exit or in IEFUJV, but IMHO it 
> would be better to deal with the failure to purge, especially if there are 
> production jobs involved. What are the change control ramifications?
>
>
> 
>
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> Mark Jacobs 0224d287a4b1-dmarc-requ...@listserv.ua.edu
> Sent: Tuesday, September 22, 2020 9:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL examination prior to execution
>
> We've had developers fill up spool with unnecessary dumps in the past. Yes, 
> you're correct, they can do as you said, but they don't. It's pure user error.
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key - 
> https://secure-web.cisco.com/1OSpskMwztP6CgrG_HtwTOihVm3MEhxDCujtfQuJj2idxt6brIDv_vLiGpp4RtOEnbU5MtT5tKax3nE8hx0u7LbxEE9XIm13DsqwoENGzP-JAXrw_n7XpyVdyLehvQrpJ2MWvRMKiYHj426mdG5TuHBLUcpEYj_VkX031AEx7sEZkfQh2kxTtIlnuX1k4gGnrZgq3o772L1H5X74RRp1l4HSIJ1rmTbUWk0C4-lk1OXpZpw1R1EmNwujypqxs0RyqFLsG-tNSrazc5Ejy7WYxZyJO4OYh1gj8p_9z_HAAK7LyuHMtSzwWfXZ_kZDmVTtjbWinOwwhv0RSXK0t_jHeE0j_uAreO15pWtX4sHmug0qKyxp--3EAaiBSmMpdIpnkKkU77iWvssHK3UXm80NMofrAEnkBiGtpFhR1zX6I3bldW3BIyD_peg89Qw5OXm23/https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, September 22, 2020 9:29 AM, Seymour J Metz sme...@gmu.edu wrote:
>
> > Why? My understanding is that you can retrieve an SVC dump from SPOOL and 
> > process it in IPCS. As long as it is in a hold class, what problems does it 
> > cause?
> >
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> > Mark Jacobs 0224d287a4b1-dmarc-requ...@listserv.ua.edu
> > Sent: Tuesday, September 22, 2020 8:11 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: JCL examination prior to execution
> > We have developers who put SYSMDUMP output to SYSOUT rather than a dataset. 
> > I'm looking at ways to prevent those jobs from executing until they make 
> > JCL changes. Are there any other exits, processes other than a JES2 exit 
> > (looking at exit 6/60) to do so?
> > Mark Jacobs
> > Sent from ProtonMail, Swiss-based encrypted email.
> > GPG Public Key - 
> > https://secure-web.cisco.com/1gV3QlDEC4whhAOpxGDqlWhtt9-Vum1-s6zU_qe0Q1Q3aPU1FE-A90GeTPpz8jKMhzcZVcfg6b6k5_7EC3d3RcoB3IEi6T0Znq9kwpDNzuoNXOFZy44tM4Lu7OcfqHR66zi9MQdIlEyX18kKI1-uyZrD1tQfcoLhPP0vvD2fG4Az6VK8S5R4449KcpF93hlyFnGO29LfHJWgTQUgwGOmsAwq5HlKn07Fugxsjgnv4dg-XtmWUi0Exd3Pt_p6cfHqmS8_GCvni0WjqRy07gZnTOMCLLVCAV8rTILJ8vtI2JEVZpf7fI3oPe2IP4BYs5pLmzCN6W1nR-27mgDwuZTDw_lMAT-WvQarzSxkU-0L75vCJNbRwEoNOVCHsX_y6FqWNwHDwIxCE2cUcMKYLjwrh1TDYQfEGK83ZQmF7emCkNwQxJTgbVBGIGNYaBrT2EsMk/https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com
> >
> > 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
>
>
> 
>
> 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: JCL examination prior to execution

[R.S.]

W dniu 22.09.2020 o 14:11, Mark Jacobs pisze:

We have developers who put SYSMDUMP output to SYSOUT rather than a dataset. I'm 
looking at ways to prevent those jobs from executing until they make JCL 
changes. Are there any other exits, processes other than a JES2 exit (looking 
at exit 6/60) to do so?


Is it production?
Assuming the above every prod job should be released by administration 
team, not by developers.

(I exclude sysprogs and admins jobs.)
Every job should follow the rules. Just because mama said so, no tool is 
needed here.
Last, but not least a process of code promotion could contain step of 
JCL review. It can be automatized using some toool, maybe RYO tool.

And finally such tool could be run against existing jobs.

--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: JCL examination prior to execution

[Seymour J Metz]

Well, you could certainly catch it in a JES exit or in IEFUJV, but IMHO it 
would be better to deal with the failure to purge, especially if there are 
production jobs involved. What are the change control ramifications?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, September 22, 2020 9:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL examination prior to execution

We've had developers fill up spool with unnecessary dumps in the past. Yes, 
you're correct, they can do as you said, but they don't. It's pure user error.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://secure-web.cisco.com/1OSpskMwztP6CgrG_HtwTOihVm3MEhxDCujtfQuJj2idxt6brIDv_vLiGpp4RtOEnbU5MtT5tKax3nE8hx0u7LbxEE9XIm13DsqwoENGzP-JAXrw_n7XpyVdyLehvQrpJ2MWvRMKiYHj426mdG5TuHBLUcpEYj_VkX031AEx7sEZkfQh2kxTtIlnuX1k4gGnrZgq3o772L1H5X74RRp1l4HSIJ1rmTbUWk0C4-lk1OXpZpw1R1EmNwujypqxs0RyqFLsG-tNSrazc5Ejy7WYxZyJO4OYh1gj8p_9z_HAAK7LyuHMtSzwWfXZ_kZDmVTtjbWinOwwhv0RSXK0t_jHeE0j_uAreO15pWtX4sHmug0qKyxp--3EAaiBSmMpdIpnkKkU77iWvssHK3UXm80NMofrAEnkBiGtpFhR1zX6I3bldW3BIyD_peg89Qw5OXm23/https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, September 22, 2020 9:29 AM, Seymour J Metz  wrote:

> Why? My understanding is that you can retrieve an SVC dump from SPOOL and 
> process it in IPCS. As long as it is in a hold class, what problems does it 
> cause?
>
>
> --
>
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> Mark Jacobs 0224d287a4b1-dmarc-requ...@listserv.ua.edu
>
> Sent: Tuesday, September 22, 2020 8:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JCL examination prior to execution
>
> We have developers who put SYSMDUMP output to SYSOUT rather than a dataset. 
> I'm looking at ways to prevent those jobs from executing until they make JCL 
> changes. Are there any other exits, processes other than a JES2 exit (looking 
> at exit 6/60) to do so?
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key - 
> https://secure-web.cisco.com/1gV3QlDEC4whhAOpxGDqlWhtt9-Vum1-s6zU_qe0Q1Q3aPU1FE-A90GeTPpz8jKMhzcZVcfg6b6k5_7EC3d3RcoB3IEi6T0Znq9kwpDNzuoNXOFZy44tM4Lu7OcfqHR66zi9MQdIlEyX18kKI1-uyZrD1tQfcoLhPP0vvD2fG4Az6VK8S5R4449KcpF93hlyFnGO29LfHJWgTQUgwGOmsAwq5HlKn07Fugxsjgnv4dg-XtmWUi0Exd3Pt_p6cfHqmS8_GCvni0WjqRy07gZnTOMCLLVCAV8rTILJ8vtI2JEVZpf7fI3oPe2IP4BYs5pLmzCN6W1nR-27mgDwuZTDw_lMAT-WvQarzSxkU-0L75vCJNbRwEoNOVCHsX_y6FqWNwHDwIxCE2cUcMKYLjwrh1TDYQfEGK83ZQmF7emCkNwQxJTgbVBGIGNYaBrT2EsMk/https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com
>
> --
>
> 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


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

Re: JCL examination prior to execution

[Mitch Mccluhan]

 just a thought.  Run the JCL through J-Man and either change the 
statements, one of the values/parameters or issue a flag prior to the execution.
Mitch
 
 
-Original Message-
From: Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tue, Sep 22, 2020 8:35 am
Subject: Re: JCL examination prior to execution

We've had developers fill up spool with unnecessary dumps in the past. Yes, 
you're correct, they can do as you said, but they don't. It's pure user error.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, September 22, 2020 9:29 AM, Seymour J Metz  wrote:

> Why? My understanding is that you can retrieve an SVC dump from SPOOL and 
> process it in IPCS. As long as it is in a hold class, what problems does it 
> cause?
>
>
> --
>
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> Mark Jacobs 0224d287a4b1-dmarc-requ...@listserv.ua.edu
>
> Sent: Tuesday, September 22, 2020 8:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JCL examination prior to execution
>
> We have developers who put SYSMDUMP output to SYSOUT rather than a dataset. 
> I'm looking at ways to prevent those jobs from executing until they make JCL 
> changes. Are there any other exits, processes other than a JES2 exit (looking 
> at exit 6/60) to do so?
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key - 
> https://secure-web.cisco.com/1gV3QlDEC4whhAOpxGDqlWhtt9-Vum1-s6zU_qe0Q1Q3aPU1FE-A90GeTPpz8jKMhzcZVcfg6b6k5_7EC3d3RcoB3IEi6T0Znq9kwpDNzuoNXOFZy44tM4Lu7OcfqHR66zi9MQdIlEyX18kKI1-uyZrD1tQfcoLhPP0vvD2fG4Az6VK8S5R4449KcpF93hlyFnGO29LfHJWgTQUgwGOmsAwq5HlKn07Fugxsjgnv4dg-XtmWUi0Exd3Pt_p6cfHqmS8_GCvni0WjqRy07gZnTOMCLLVCAV8rTILJ8vtI2JEVZpf7fI3oPe2IP4BYs5pLmzCN6W1nR-27mgDwuZTDw_lMAT-WvQarzSxkU-0L75vCJNbRwEoNOVCHsX_y6FqWNwHDwIxCE2cUcMKYLjwrh1TDYQfEGK83ZQmF7emCkNwQxJTgbVBGIGNYaBrT2EsMk/https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com
>
> --
>
> 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

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

Re: JCL examination prior to execution

[Mark Jacobs]

We've had developers fill up spool with unnecessary dumps in the past. Yes, 
you're correct, they can do as you said, but they don't. It's pure user error.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, September 22, 2020 9:29 AM, Seymour J Metz  wrote:

> Why? My understanding is that you can retrieve an SVC dump from SPOOL and 
> process it in IPCS. As long as it is in a hold class, what problems does it 
> cause?
>
>
> --
>
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> Mark Jacobs 0224d287a4b1-dmarc-requ...@listserv.ua.edu
>
> Sent: Tuesday, September 22, 2020 8:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JCL examination prior to execution
>
> We have developers who put SYSMDUMP output to SYSOUT rather than a dataset. 
> I'm looking at ways to prevent those jobs from executing until they make JCL 
> changes. Are there any other exits, processes other than a JES2 exit (looking 
> at exit 6/60) to do so?
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key - 
> https://secure-web.cisco.com/1gV3QlDEC4whhAOpxGDqlWhtt9-Vum1-s6zU_qe0Q1Q3aPU1FE-A90GeTPpz8jKMhzcZVcfg6b6k5_7EC3d3RcoB3IEi6T0Znq9kwpDNzuoNXOFZy44tM4Lu7OcfqHR66zi9MQdIlEyX18kKI1-uyZrD1tQfcoLhPP0vvD2fG4Az6VK8S5R4449KcpF93hlyFnGO29LfHJWgTQUgwGOmsAwq5HlKn07Fugxsjgnv4dg-XtmWUi0Exd3Pt_p6cfHqmS8_GCvni0WjqRy07gZnTOMCLLVCAV8rTILJ8vtI2JEVZpf7fI3oPe2IP4BYs5pLmzCN6W1nR-27mgDwuZTDw_lMAT-WvQarzSxkU-0L75vCJNbRwEoNOVCHsX_y6FqWNwHDwIxCE2cUcMKYLjwrh1TDYQfEGK83ZQmF7emCkNwQxJTgbVBGIGNYaBrT2EsMk/https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com
>
> --
>
> 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: JCL examination prior to execution

[Mark Jacobs]

Thanks.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, September 22, 2020 9:06 AM, Binyamin Dissen 
 wrote:

> IEAVTABX.
>
> Real time, when there is a dump.
>
> Check if SYSMDUMP is to SYSOUT, and then suppress it.
>
> On Tue, 22 Sep 2020 12:11:43 + Mark Jacobs
> 0224d287a4b1-dmarc-requ...@listserv.ua.edu wrote:
>
> :>We have developers who put SYSMDUMP output to SYSOUT rather than a dataset. 
> I'm looking at ways to prevent those jobs from executing until they make JCL 
> changes. Are there any other exits, processes other than a JES2 exit (looking 
> at exit 6/60) to do so?
>
> --
>
> Binyamin Dissen bdis...@dissensoftware.com
>
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>
> ---
>
> 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: JCL examination prior to execution

[Seymour J Metz]

Why? My understanding is that you can retrieve an SVC dump from SPOOL and 
process it in IPCS. As long as it is in a hold class, what problems does it 
cause?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, September 22, 2020 8:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL examination prior to execution

We have developers who put SYSMDUMP output to SYSOUT rather than a dataset. I'm 
looking at ways to prevent those jobs from executing until they make JCL 
changes. Are there any other exits, processes other than a JES2 exit (looking 
at exit 6/60) to do so?

Mark Jacobs

Sent from 
[ProtonMail](https://secure-web.cisco.com/1UJ0XuLv8s_FsNGsgYC7U22TV1QPltXYY8pHaFOPj7KyX0ugVH0OZEWNsTt7B97cN_33CVcPXURhfBnR4hpsQJee8ls6F4eE8T9Cqp8cD1onKHPclqWPjsjIFJBoUl7qwc-lWv9T0ZJTb7II9LpbFw1YjwkxQTDceoxGJByH0kShqPHR151KlemuYRaOni4JJZqCTbR2Oqn-xgHXiSd-Qh-zuZDYR2HuEwlob9Qj6VkPa8xyRhbqAGY5HlcwC9Bfl1vvfV-fHaSuEpCMN_3EddSqiMbESYUqg_oe0YGpD1T4DcqAVXJDXqcRpeFvHPrs3kRpt6XgGUZofZJII-GUoL9IEtP_kwyZoNgER3c-yNG4qSAo6lK_dhJHGyYpCqBbPuq0sFzNYRxT7DXXxuj7oiZ2osOQq-_VBpnTeXItumhNldMmNKeAi-_63AxuiBQVR/https%3A%2F%2Fprotonmail.com),
 Swiss-based encrypted email.

GPG Public Key - 
https://secure-web.cisco.com/1gV3QlDEC4whhAOpxGDqlWhtt9-Vum1-s6zU_qe0Q1Q3aPU1FE-A90GeTPpz8jKMhzcZVcfg6b6k5_7EC3d3RcoB3IEi6T0Znq9kwpDNzuoNXOFZy44tM4Lu7OcfqHR66zi9MQdIlEyX18kKI1-uyZrD1tQfcoLhPP0vvD2fG4Az6VK8S5R4449KcpF93hlyFnGO29LfHJWgTQUgwGOmsAwq5HlKn07Fugxsjgnv4dg-XtmWUi0Exd3Pt_p6cfHqmS8_GCvni0WjqRy07gZnTOMCLLVCAV8rTILJ8vtI2JEVZpf7fI3oPe2IP4BYs5pLmzCN6W1nR-27mgDwuZTDw_lMAT-WvQarzSxkU-0L75vCJNbRwEoNOVCHsX_y6FqWNwHDwIxCE2cUcMKYLjwrh1TDYQfEGK83ZQmF7emCkNwQxJTgbVBGIGNYaBrT2EsMk/https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com

--
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: JCL examination prior to execution

[Binyamin Dissen]

IEAVTABX.

Real time, when there is a dump. 

Check if SYSMDUMP is to SYSOUT, and then suppress it.

On Tue, 22 Sep 2020 12:11:43 + Mark Jacobs
<0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

:>We have developers who put SYSMDUMP output to SYSOUT rather than a dataset. 
I'm looking at ways to prevent those jobs from executing until they make JCL 
changes. Are there any other exits, processes other than a JES2 exit (looking 
at exit 6/60) to do so?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

JCL examination prior to execution

[Mark Jacobs]

We have developers who put SYSMDUMP output to SYSOUT rather than a dataset. I'm 
looking at ways to prevent those jobs from executing until they make JCL 
changes. Are there any other exits, processes other than a JES2 exit (looking 
at exit 6/60) to do so?

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

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

Re: rename a dataset in acs routine?

[R.S.]

My €0.02:
This is typical problem when the goal is NOT defined.
Existing approach seems ridiculous, but it exists. It works.
So, since it works, why to change it? What is the reason? What goal is 
to achieve?

More ridiculous are the terms. JCL cannot be changed. WHY???
However JES2 exit6 which changes JCL "in the flight" is allowed. Why???
Datasets are important, but the chances it will be ever read are small.
Uncataloged datasets are a problem, however there is no big problem with 
duplicate names and volser which is known after the dataset is created.


My opinion:
First, recognize the situation and define the problem, then define the goal.
Never use tapes, especially for small datasets. Including virtual tapes.
Small datasets can be written to DASD, zEDC can be used to compress it. 
And DFSMS MC can be used to migrate it to tape. Yes, tapes are still 
good for backup and ML2.
Large number of datasets is not a problem, that's what are user catalogs 
for.

Good naming convention will help with ACS routines and ICF aliases.
It can be GDG or just HLQ.YEAR.SOME.NAME.Ddate, or so. I would not go to 
PDSE members. Member are good candidate for really big number of really 
small files. Note, the smallest chunk of DASD is one track. The smallest 
chunk of PDSE is 4kB, and for PDS is just the size of file, it can be 
one byte. However migrated dataset occupies zero tracks.
All the revolution require ...just simple changes in JCL and few changes 
in DFSMS realm. I can do that for peanuts ;-)


--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: Caution: "Hacked" email caused the distribution of a potentially harmful attachment

[R.S.]

Bob,
Yes you correctly interpreted my point about the language in scam emails.

However ...it is NOT MY observation. I'm only messenger. This is 
recognized by proffessionals who work (fight) with scam and Internet 
security, and study the problem.

And it is reasonable, not preposterous.

Few remarks:
1. Scam is a business. Yes, it is a crime, but many crimes are 
profitable and well organized. Like drugs.
2. This business is NOT driven by idiots. There are clever people who 
cheats. Charles Ponzi, Jordan Belfort, Bernard Madoff, Zeek Rewards, 
OSGold, PIPS...
3. Assumption that nigerian scam is driven by nigerian poeple is plain 
wrong.
4. Every crime group is clever enough to hire some native speaker to 
edit some short message without errors and dumb mistakes.
5. Nigerian scam is common name for some type of trick and does not 
necessarily mean anything related to Nigeria. In Poland we have scam 
mails from "US Army soldier", usually from some base in Iraq or Germany. 
And there are more scam topics.
6. Most scam emails are in native language of recipient. So, in Poland 
we have emails in polish, nevermind how the "US Army Soldier" learnt 
this language (usually because of polish roots). And phony nigerian 
minister studied in Poland, which sound reasonable, because we have many 
students from Africa and Middle East (and Latin America).


--
Radoslaw Skorupka
Lodz, Poland






W dniu 22.09.2020 o 01:04, Bob Bridges pisze:

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, September 21, 2020 17:08

JR> The idea of deliberately dumbing down language in spam is preposterous. 
First of all I don't understand the purported logic of it.

BB> Radoslaw's logic seemed clear to me, but when I set out to spell it out for you, I 
began to wonder whether I'd mistaken it.  He wrote "a method to filter out bright 
people and leave only the fools", which I interpreted this way:  Intelligent people 
(according to Radoslaw) are less likely to produce profit for the scammer, in the long run.  
If the scam is written badly, an intelligent person is more likely to throw it out, and thus 
less likely to waste the scammer's time with replies that will in the end lead nowhere.  
Fools, meanwhile, will not notice (or notice less) the atrocious writing, and thus be more 
likely to proceed.

I'll leave it to him to say whether I read him correctly.  But ~if~ that is 
indeed the scammer's motive for writing badly, I think the scammer isn't 
thinking very clearly.

The next part of your comment I think is just a confusion about who said what.  I said 
Nigerians are mostly capable of better English than I see in "Nigerian old 
ministers' " emails, but that's just a side comment, not part of Radoslaw's 
reasoning.

JR> More important, while English is an official language in Nigeria, it is no 
one's mother tongue. It's learned, mostly in school, to whatever proficiency the 
learner can achieve. The average spammer has probably never stepped inside 
university. Even secondary school certification is improbable. Add to that the 
'dialectical' difference between Nigerian and American English makes it unlikely 
that the most fluent spammer could write something of undetectable of origin.

BB> I don't buy that last part.  I have no idea how many spammers have been to University, or 
secondary school, but they can't ~all~ be illiterate and therefore it's not unlikely - just the 
reverse - that some of them will be able to compose a grammatically correct email.  No one said 
anything about "undetectable"; for verisimilitude you'd want ~some~ degree of 
"foreign-ness".

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* ...in your bedchamber do not curse a king, and in your sleeping rooms do not 
curse a rich man, for a bird of the heavens will carry the sound, and the 
winged creature will make the matter known.  -Ecclesiastes 10:20 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, September 21, 2020 10:19 AM

Interesting hypothesis.  I always supposed that they were badly written either 
because a) scammers don't care (which is perhaps another way of saying they're 
illiterate, or b) these Nigerian-oil-minister scams actually are written by 
foreigners whose English is bad - not, perhaps, by actual Nigerians, whose 
English is usually better than that - or c) they want to ~appear~ to be written 
by Nigerians.  It never occurred to me that it might be an anti-intelligence 
filter.

But then, I take it as an article of faith that it's not intelligence that'll save you 
from being scammed.  It's not the smart people who fall for "I want you to handle my 
money for me"; it's the greedy ones.  And greedy people are foolish, but they're not 
necessarily stupid.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: