Re: LE and 64-bit applications

[Don Poitras]

In article  
you wrote:
> On Fri, Dec 1, 2017 at 6:21 PM, Frank Swarbrick  > wrote:

> > I had the thought to test calling LE routines from the Swift beta.  I have
> > been successful in calling a couple of the routines that are declared in
> > the __le_api.h header.  But it appears that the CEE* routines are not
> > available in 64-bit mode.  Is this true?  If so, any idea why?
> >

snip

> ?So I'm thinking that AMODE(64) is basically only for C & HLASM and you
> _must_ use the 64-bit C subroutine ?library and/or the BPX4* (UNIX) and/or
> assembler macros which handle 64-bits.

You can run AMODE(64) without LE at all if you wish. If you want to
use LE functions, then you must compile XPLINK and use the 64-bit
libraries. HLASM can be coded for subroutines, but can't be the main(),
so you can't have _just_ HLASM running AMODE64 using LE. PL1 was also
recently added to the 64-bit family.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: IBM does what IBM does best: Raises the chopper again

[Edward Gould]

> On Dec 1, 2017, at 11:17 AM, Pommier, Rex  wrote:
> 
> The number of employees left at IBM in 5 years in the United States?  :-)>   
> FTFY.
> 
> Rex

It will take 110 to manage 42.

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

Re: IBM does what IBM does best: Raises the chopper again

[Edward Gould]

> On Dec 1, 2017, at 10:26 AM, Mike Schwab  wrote:
> 
> And check out the first two religious meanings for 42:  In Japanese,
> pronouncing the two digits is the same as the word for death.  In
> Egypt, 42 questions are asked of a dead person.
> https://en.wikipedia.org/wiki/42_(number)#Religion 
> 
The real question was  did they answer back?

Ed


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

Re: IBM does what IBM does best: Raises the chopper again

[Edward Gould]

> On Nov 30, 2017, at 11:37 AM, Ed Jaffe  wrote:
> 
> On 11/29/2017 10:45 PM, Edward Gould wrote:
>>> On Nov 29, 2017, at 8:33 PM, Jack J. Woehr >> > wrote:
>>> 
>>> Famously, Thomas J. Watson, Jr. said around 1950 "Nobody's going to buy 
>>> computers. The whole world will need about four of them.”
>> Yes and I have heard the story about gates and more than 64K.
> 
> That was 640K.

Right you are, my fingers dropped a digit, I apologize.

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


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

Re: Since it's Friday

[Tony Harminc]

On 1 December 2017 at 15:43, Pew, Curtis G 
wrote:

> This is just a curiosity question, but I’ve wondered about this.
>
> The JCL reference says:
>
> All temporary data set names begin as follows:
> SYSyyddd.Thhmmss.RA000.jjobname
>
> Does anyone know the story behind the ‘RA000’ part? It seems unnecessary
> and arbitrary.
>

I know just one little bit about it. In MVT, this qualifier was RVnnn, and
I *think* it was RF in MFT. The RA came along with MVS. IIRC the A stands
for AOS (Advanced Operating System), one of the early names for MVS.

Tony H.

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

Re: Cobol File Question

[Savor, Thomas (Alpharetta)]

In your call to the second program...that has the FD, he owns the file.  If he 
is always opening the file on every call and "should" close file on 
exitthen I would be looking into where you can get out of 2nd program 
without executing Close.  Something like an error.

Thanks,

Tom Savor
Software Developer, Sr
FRMS-SCM
Fiserv
Office:  678-375-1307
Mobile: 404-660-6898
Fax:  678-375-3280
www.fiserv.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Friday, December 01, 2017 5:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol File Question

John,

Yes exactly.., until I can convince an overly cautious manager we should thread 
or multi-task.

Thanks , John..I needed a sanity check

On Dec 1, 2017, 4:55 PM -0500, John McKown , 
wrote:
> On Fri, Dec 1, 2017 at 3:42 PM, scott Ford  wrote:
>
> > All:
> >
> > Sorry for the Cobol question but i have a question..
> > I have s single thread STC calling a second Cobol program that 
> > second program opens files ( sysprint - defined as sequential ) and 
> > writes output. I need to close these files on termination of the STC.
> > We have built an API ...my thought is to pass a variable indicating 
> > to close the files and set a return-code and return back and have 
> > the STC check it..
> >
>
> ​OK. Your COBOL program #1 is doing a COBOL dynamic CALL of this 
> second program. The second program is doing an COBOL OPEN verb on an 
> FD whose SELECT is for DD SYSPRINT,? Am I correct so far? The second 
> program is not doing a COBOL CLOSE on the FD. When the second COBOL 
> program does a GOBACK, it returns to the first program. When the first 
> program terminates, the STC terminates. In this case, where some 
> program does an OPEN but there is no corresponding CLOSE, z/OS itself 
> will do a CLOSE on all still OPEN DDs when the __TCB__ under which 
> some program did the OPEN terminates. This is because OPEN chains DEBs 
> for all OPEN DDs on the TCB under which the OPEN was done. So if there 
> are any DEBs left on this chain, task termination does a CLOSE on them. This 
> is not good practice, but it generally works.
> VSAM data sets get an "abnormal close" set in the catalog for the DSN 
> which causes an "automatic VERIFY" when the VSAM cluster is next OPEN'd.
>
> Or am I totally off base as to what you are asking?
>
>
>
> >
> > Am i thinking right ?
> >
> > --
> >
> > *IDMWORKS *
> >
> > Scott Ford
> >
> > z/OS Dev.
> >
>
>
> --
> I have a theory that it's impossible to prove anything, but I can't 
> prove it.
>
> Maranatha! <><
> John McKown
>
> --
> 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: LE and 64-bit applications

[John McKown]

On Fri, Dec 1, 2017 at 6:21 PM, Frank Swarbrick  wrote:

> I had the thought to test calling LE routines from the Swift beta.  I have
> been successful in calling a couple of the routines that are declared in
> the __le_api.h header.  But it appears that the CEE* routines are not
> available in 64-bit mode.  Is this true?  If so, any idea why?
>

​From:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea300/clscen1.htm

[quote]

*Restriction:* Language Environment services are not supported for AMODE 64
applications.

[/quote]​

However, there is this:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ceeam00/toc.htm

[quote from
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ceeam00/overv.htm
]

Introduction to Language Environment for AMODE 64 applications

Language Environment supports 64-bit addressing for applications written in
C, C++, or Language Environment-conforming Assembler.

In the 64-bit addressing mode (AMODE 64) Language Environment supports
addresses that are 64 bits in length, which allows access to data in
virtual storage up to 16 exabytes. Hence applications that work with large
databases or large volumes of data can consolidate data in one address
space. There are a few things to note:

An AMODE 64 Language Environment® application supports XPLINK linkage only
and the C runtime environment is always initialized. A new library,
CELQLIB, is shipped for AMODE 64 support, while the existing libraries
continue to be shipped and supported.
Preinitialized environments are supported via CELQPIPI.
The user stack and heap, along with most of Language Environment storage is
above the 2 GB bar.
There is a new anchor for AMODE 64 applications so register 12 no longer
needs to be reserved for the address of the CAA.
The only means of communication between AMODE 64 and AMODE 24 or AMODE 31
applications is through mechanisms that can communicate across processes or
address spaces. However, Language Environment applications that use AMODE
64 can run with existing applications that use AMODE 24 or AMODE 31 on the
same physical z/OS® system.
Where necessary, there are new Language Environment runtime options to
support AMODE 64 applications. The new runtime options primarily support
the new stack and heap storage located above the bar. Some of the existing
options are no longer available.

[/quote]

​So I'm thinking that AMODE(64) is basically only for C & HLASM and you
_must_ use the 64-bit C subroutine ​library and/or the BPX4* (UNIX) and/or
assembler macros which handle 64-bits.



>
> I have no particular need for this, but I thought it would be interesting
> to do.
>
> Thanks,
> Frank
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: LE and 64-bit applications

[Charles Mills]

CEE.SCEEBND2 rather than CEE.SCEELKED?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Friday, December 1, 2017 4:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LE and 64-bit applications

I had the thought to test calling LE routines from the Swift beta.  I have
been successful in calling a couple of the routines that are declared in the
__le_api.h header.  But it appears that the CEE* routines are not available
in 64-bit mode.  Is this true?  If so, any idea why?

I have no particular need for this, but I thought it would be interesting to
do.

Thanks,
Frank

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

LE and 64-bit applications

[Frank Swarbrick]

I had the thought to test calling LE routines from the Swift beta.  I have been 
successful in calling a couple of the routines that are declared in the 
__le_api.h header.  But it appears that the CEE* routines are not available in 
64-bit mode.  Is this true?  If so, any idea why?

I have no particular need for this, but I thought it would be interesting to do.

Thanks,
Frank

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

Re: Cobol File Question

[scott Ford]

John,

Yes exactly.., until I can convince an overly cautious manager we should thread 
or multi-task.

Thanks , John..I needed a sanity check

On Dec 1, 2017, 4:55 PM -0500, John McKown , 
wrote:
> On Fri, Dec 1, 2017 at 3:42 PM, scott Ford  wrote:
>
> > All:
> >
> > Sorry for the Cobol question but i have a question..
> > I have s single thread STC calling a second Cobol program
> > that second program opens files ( sysprint - defined as sequential ) and
> > writes output. I need to close these files on termination of the STC.
> > We have built an API ...my thought is to pass a variable indicating to
> > close the files
> > and set a return-code and return back and have the STC check it..
> >
>
> ​OK. Your COBOL program #1 is doing a COBOL dynamic CALL of this second
> program. The second program is doing an COBOL OPEN verb on an FD whose
> SELECT is for DD SYSPRINT,? Am I correct so far? The second program is not
> doing a COBOL CLOSE on the FD. When the second COBOL program does a GOBACK,
> it returns to the first program. When the first program terminates, the STC
> terminates. In this case, where some program does an OPEN but there is no
> corresponding CLOSE, z/OS itself will do a CLOSE on all still OPEN DDs when
> the __TCB__ under which some program did the OPEN terminates. This is
> because OPEN chains DEBs for all OPEN DDs on the TCB under which the OPEN
> was done. So if there are any DEBs left on this chain, task termination
> does a CLOSE on them. This is not good practice, but it generally works.
> VSAM data sets get an "abnormal close" set in the catalog for the DSN which
> causes an "automatic VERIFY" when the VSAM cluster is next OPEN'd.
>
> Or am I totally off base as to what you are asking?
>
>
>
> >
> > Am i thinking right ?
> >
> > --
> >
> > *IDMWORKS *
> >
> > Scott Ford
> >
> > z/OS Dev.
> >
>
>
> --
> I have a theory that it's impossible to prove anything, but I can't prove
> it.
>
> Maranatha! <><
> John McKown
>
> --
> 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: Passing data from step-to-step in single job using memory??

[Paul Gilmartin]

On Fri, 1 Dec 2017 15:09:07 -0600, John McKown wrote:

>On Fri, Dec 1, 2017 at 1:40 PM, Tom Marchant wrote:
>>
>> Can you run both programs in one step? Perhaps the first one calls the
>> second, or they are both called by a third program. The third program can
>> pass an area for the first to save the info and the second to retrieve it.
>>
I'd call that a specific rather than a general solution.

>I didn't go into the really weird experimentation that I'm doing. I'm a
>just "messing around" with the BPX1EXM (execmvs) UNIX function.  ...
>
Does BPX1EXM pass descriptors?  Environment variables?  I'd consider
the latter less likely.

>Now, I can pass up to 32767 bytes from my program to the next
>program via the standard "batch" PARM= equivalent. This can be arbitrary
>byte values (range x'00' to x'FF'). So I'll probably just use that
>facility. Hopefully I will never need more than 32767 bytes. Hum, could it
>really be x'' bytes? I'll need to check that out.
> 
Depends.  Using Rexx address ATTCHPGM, I've called BPXBATCH with x''
byte parm and orderly behavior.  With HLASM I've passed X'7FFF' byte parm
and orderly behavior; with x'8000', HLASM program checked after issuing
several hundred thousand lines of error messages.  LH with sign extension?

How much should the called routine validate PARM?  Verify length?  Verify
that PARM lies within addressable memory?

-- gil

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

Re: Passing data from step-to-step in single job using memory??

[John McKown]

On Fri, Dec 1, 2017 at 3:49 PM, Walt Farrell  wrote:

> On Fri, 1 Dec 2017 15:09:07 -0600, John McKown <
> john.archie.mck...@gmail.com> wrote:
>
>
> >I didn't go into the really weird experimentation that I'm doing. I'm a
> >just "messing around" with the BPX1EXM (execmvs) UNIX function. This is a
> >real weirdie (to me). It basically terminates the current job step, then
> >_inserts_ a new job step (which shows up with *OMVSEX as the step name)
> >immediately _after_ the current job step and _before_ the next JCL job
> >step. I'm still in the same ASID, but all the JCL has disappeared and all
> >the user allocated memory is gone (non APF can't get LSQA which would
> >survive). Now, I can pass up to 32767 bytes from my program to the next
> >program via the standard "batch" PARM= equivalent. This can be arbitrary
> >byte values (range x'00' to x'FF'). So I'll probably just use that
> >facility. Hopefully I will never need more than 32767 bytes. Hum, could it
> >really be x'' bytes? I'll need to check that out.
> >
> >I'm just messing around with this and wanted an easy way for my invoker to
> >send more data to the invokee. I could cheat and use UNIX message queues.
> >But they are not cleaned up at job end.
>
> Wouldn't it be more "UNIX-ish" if you forked, then did the execmvs in the
> new address space? You could create a pipe to transfer the data between the
> two.
>

Very true. I'm still just "messing around" and if I can do something with
BPX1EXM instead of doing a fork() or spawn(), I'll use less resource. Also,
the output from the "inserted step" (like WTOs et al.) show up in the job's
JESMSGLG instead of "somewhere else" with nothing showing in the original
job. I'm pretty sure that's correct. I may check it out -- but it's go home
time, so I'm outta here!​



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



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Cobol File Question

[John McKown]

On Fri, Dec 1, 2017 at 3:42 PM, scott Ford  wrote:

> All:
>
> Sorry for the Cobol question but i have a question..
> I have s single thread STC calling a second Cobol program
> that second program opens files ( sysprint - defined as sequential ) and
> writes output.  I need to close these files on termination of the STC.
> We have built an API ...my thought is to pass a variable indicating to
> close the files
> and set a return-code and return back and have the STC check it..
>

​OK. Your COBOL program #1 is doing a COBOL dynamic CALL of this second
program. The second program is doing an COBOL OPEN verb on an FD whose
SELECT is for DD SYSPRINT,?  Am I correct so far? The second program is not
doing a COBOL CLOSE on the FD. When the second COBOL program does a GOBACK,
it returns to the first program. When the first program terminates, the STC
terminates. In this case, where some program does an OPEN but there is no
corresponding CLOSE, z/OS itself will do a CLOSE on all still OPEN DDs when
the __TCB__ under which some program did the OPEN terminates. This is
because OPEN chains DEBs for all OPEN DDs on the TCB under which the OPEN
was done. So if there are any DEBs left on this chain, task termination
does a CLOSE on them. This is not good practice, but it generally works.
VSAM data sets get an "abnormal close" set in the catalog for the DSN which
causes an "automatic VERIFY" when the VSAM cluster is next OPEN'd.

Or am I totally off base as to what you are asking?



>
> Am i thinking right ?
>
> --
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Passing data from step-to-step in single job using memory??

[Walt Farrell]

On Fri, 1 Dec 2017 15:09:07 -0600, John McKown  
wrote:


>I didn't go into the really weird experimentation that I'm doing. I'm a
>just "messing around" with the BPX1EXM (execmvs) UNIX function. This is a
>real weirdie (to me). It basically terminates the current job step, then
>_inserts_ a new job step (which shows up with *OMVSEX as the step name)
>immediately _after_ the current job step and _before_ the next JCL job
>step. I'm still in the same ASID, but all the JCL has disappeared and all
>the user allocated memory is gone (non APF can't get LSQA which would
>survive). Now, I can pass up to 32767 bytes from my program to the next
>program via the standard "batch" PARM= equivalent. This can be arbitrary
>byte values (range x'00' to x'FF'). So I'll probably just use that
>facility. Hopefully I will never need more than 32767 bytes. Hum, could it
>really be x'' bytes? I'll need to check that out.
>
>I'm just messing around with this and wanted an easy way for my invoker to
>send more data to the invokee. I could cheat and use UNIX message queues.
>But they are not cleaned up at job end.

Wouldn't it be more "UNIX-ish" if you forked, then did the execmvs in the new 
address space? You could create a pipe to transfer the data between the two.

-- 
Walt

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

UNIX tmpfile() (was: Passing data ...?)

[Paul Gilmartin]

On Fri, 1 Dec 2017 14:55:08 -0600, John McKown wrote:
>
>> And the OS feature I miss most in UNIX is temporary data sets.
>
>​Yes, very much. My method, in general, is to create a "temporary" file in
>the ${TMP} directory. Open it. Unlink the file entry. Use the FILE * and
>pass it around to other programs so that they can access the data.​
> 
It's easier than that.  In:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/tmpfile.html#tag_16_618_03
... In some implementations, a permanent file may be left behind if the 
process calling
tmpfile() is killed while it is processing a call to tmpfile().

This is the exception that proves the rule that once tmpfile() nas completed
killing the calling process leaves no permanent file behind.  tmpfile() ought to
unlink the file before returning.

Unlike most UNIXen, the earliest OMVS violated this, deleting the temporary file
only when the process exited.  I suspect this was an accommodation to 
implementing
temporary files as Classic data sets.  I believe it's better now.  Don't know 
about
POSIX(OFF).

As an alternative, you could pass just the descriptor.

Of course, this doesn't cross job step boundaries.  Alas, JCL doesn't support
temporary UNIX files.

-- gil

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

Cobol File Question

[scott Ford]

All:

Sorry for the Cobol question but i have a question..
I have s single thread STC calling a second Cobol program
that second program opens files ( sysprint - defined as sequential ) and
writes output.  I need to close these files on termination of the STC.
We have built an API ...my thought is to pass a variable indicating to
close the files
and set a return-code and return back and have the STC check it..

Am i thinking right ?

-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: Passing data from step-to-step in single job using memory??

[John McKown]

On Fri, Dec 1, 2017 at 1:40 PM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 1 Dec 2017 12:22:41 -0600, John McKown wrote:
> >
> >​Yeah. My "problem" is not with VIO, but with QSAM. Writing a RENT,REUS
> >HLASM program which I want to be AMODE(31),RMODE(ANY) is just a PITA with
> >QSAM. I was hoping for an easier API.​
>
> Why a PITA? If you are RENT, you will need to GETMAIN some storage.
> To create a DCB, you will need storage below the line. Big deal. Unless
> your program's storage requirements are large, you could make all of
> your GETMAINed storage below the line.
>

​Well, I'm just generally griping, I guess. Bad week. I wish that IBM had
generalized the VSAM "GENCB" idea; which didn't really seem to catch on
(which may explain why it didn't get expanded). I also wish that IBM had
made an ACB oriented access to PS and PO data sets.​



>
> Can you run both programs in one step? Perhaps the first one calls the
> second, or they are both called by a third program. The third program can
> pass an area for the first to save the info and the second to retrieve it.
>

I didn't go into the really weird experimentation that I'm doing. I'm a
just "messing around" with the BPX1EXM (execmvs) UNIX function. This is a
real weirdie (to me). It basically terminates the current job step, then
_inserts_ a new job step (which shows up with *OMVSEX as the step name)
immediately _after_ the current job step and _before_ the next JCL job
step. I'm still in the same ASID, but all the JCL has disappeared and all
the user allocated memory is gone (non APF can't get LSQA which would
survive). Now, I can pass up to 32767 bytes from my program to the next
program via the standard "batch" PARM= equivalent. This can be arbitrary
byte values (range x'00' to x'FF'). So I'll probably just use that
facility. Hopefully I will never need more than 32767 bytes. Hum, could it
really be x'' bytes? I'll need to check that out.

I'm just messing around with this and wanted an easy way for my invoker to
send more data to the invokee. I could cheat and use UNIX message queues.
But they are not cleaned up at job end.



>
> --
> Tom Marchant
>
>

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Passing data from step-to-step in single job using memory??

[Farley, Peter x23353]

Is it possible to keep z/Unix 64-bit Memory Objects across a job step boundary? 
 Or like name/tokens, do such persistent objects require APF authorization 
and/or supervisor state?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, December 1, 2017 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Passing data from step-to-step in single job using memory??

EXTERNAL: This email originated from outside of Broadridge. Do not click any 
links or open any attachments unless you trust the sender and know the content 
is safe.

On Fri, Dec 1, 2017 at 1:20 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 1 Dec 2017 12:22:41 -0600, John McKown wrote:
> >
> >​Yeah. My "problem" is not with VIO, but with QSAM. Writing a RENT,REUS
> >HLASM program which I want to be AMODE(31),RMODE(ANY) is just a PITA with
> >QSAM. I was hoping for an easier API.​
> >
> Name-token services?
>

​Nope - you can't create a "job level" name-token. Non-APF code can only
create a "step" level which goes away at end of step. A system level
name-token requires APF authorization and is not cleaned up automatically
and end of job.​



>
> Batchpipes?
>

​Don't own it.​



>
> LINK to a QSAM library subroutine, RMODE 24, AMODE ANY with arguments:
> o DDNAME
> o Read/write flag
> o Data length
> o Data address
>

​A generic routine which can do a dynamic allocation of a DCB, fill in the
DD name, then open it on the first call, returning a pointer to the caller.
The caller then calls again with what you indicated (plus the pointer to
the structure returned initially).​



>
> This is oddly similar to the UNIX limitation that a child process can't
> modify the
> parent's environment variables.
>

​That sort of makes sense to me. The child is running in a separate address
space from the parent. To change the variables in the parent would require
running code in the parent's address space to do the "putenv()" type call.
In z/OS this would be possible by scheduling an SRB into the parent which
then schedules an IRB to run on the TCB running the shell code. ​



>
> And the OS feature I miss most in UNIX is temporary data sets.
>

​Yes, very much. My method, in general, is to create a "temporary" file in
the ${TMP} directory. Open it. Unlink the file entry. Use the FILE * and
pass it around to other programs so that they can access the data.​



>
> -- gil
>
>

-- 


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

[Seymour J Metz]

What was advertised was that a main program was just another subroutine. OS/360 
did not advertise that the caller of a subroutine would always pass correct 
parameters.


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


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Friday, December 1, 2017 3:48 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: LONGPARM

> Many programs depended on the documented restriction that JCL-supplied parms 
> could
> not exceed 100 bytes. While this may not be *the* greatest design, it was 
> common.

And in fairness, we were constrained in those days by limited memory, 4K base 
register issues and relatively slow instruction times. Why waste bytes, 
addressability and cycles just to make sure OS/360 was behaving as advertised?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Friday, December 1, 2017 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LONGPARM

On 30 November 2017 at 22:26, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

>
> >You can *never* pass more than 100 bytes via PARM=. If you want a
> >longer parameter, you *must* use PARMDD.
> >
> >The interface as seen by the program is the same in both cases:
> >halfword length followed by data.
>
> What about the ATTACH, XCTL, LINK, and LOAD/CALL macros.  Prior to the
> innovation of the LONGPARM attribute it was the responsibility of
> either the parent or child task (not clearly documented which?) to
> verify PARM length.


There is nothing in the nature of ATTACH, XCTL, LINK or LOAD/CALL that suggests 
the argument(s) must be of the form halfword length followed by data. And 
indeed it's very often the case that internal routines have R1 pointing at some 
quite different data structure. For that matter R1 doesn't have to be a valid 
pointer at all. Any checking/rejection at the system level that assumed this 
kind of argument would cause huge breakage all over the place.


> Do these nowadays respect the NOLONGPARM setting?
>

Clearly not. They have no way of knowing what kind of data the called program 
is expecting.

A defensively coded subroutine should *always* validate its arguments.
>

No argument. (Yeah, I know...)

> It seems OS/360 developers were unaware of this.

I don't know why you say that. I think we've been through this a zillion times 
on this list. Many programs depended on the documented restriction that 
JCL-supplied parms could not exceed 100 bytes. While this may not be
*the* greatest design, it was common. There was no integrity exposure until 
facilities to pass in long parms to a job step program became

--
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: Passing data from step-to-step in single job using memory??

[John McKown]

On Fri, Dec 1, 2017 at 1:20 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 1 Dec 2017 12:22:41 -0600, John McKown wrote:
> >
> >​Yeah. My "problem" is not with VIO, but with QSAM. Writing a RENT,REUS
> >HLASM program which I want to be AMODE(31),RMODE(ANY) is just a PITA with
> >QSAM. I was hoping for an easier API.​
> >
> Name-token services?
>

​Nope - you can't create a "job level" name-token. Non-APF code can only
create a "step" level which goes away at end of step. A system level
name-token requires APF authorization and is not cleaned up automatically
and end of job.​



>
> Batchpipes?
>

​Don't own it.​



>
> LINK to a QSAM library subroutine, RMODE 24, AMODE ANY with arguments:
> o DDNAME
> o Read/write flag
> o Data length
> o Data address
>

​A generic routine which can do a dynamic allocation of a DCB, fill in the
DD name, then open it on the first call, returning a pointer to the caller.
The caller then calls again with what you indicated (plus the pointer to
the structure returned initially).​



>
> This is oddly similar to the UNIX limitation that a child process can't
> modify the
> parent's environment variables.
>

​That sort of makes sense to me. The child is running in a separate address
space from the parent. To change the variables in the parent would require
running code in the parent's address space to do the "putenv()" type call.
In z/OS this would be possible by scheduling an SRB into the parent which
then schedules an IRB to run on the TCB running the shell code. ​



>
> And the OS feature I miss most in UNIX is temporary data sets.
>

​Yes, very much. My method, in general, is to create a "temporary" file in
the ${TMP} directory. Open it. Unlink the file entry. Use the FILE * and
pass it around to other programs so that they can access the data.​



>
> -- gil
>
>

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: LONGPARM

[Charles Mills]

> Many programs depended on the documented restriction that JCL-supplied parms 
> could 
> not exceed 100 bytes. While this may not be *the* greatest design, it was 
> common.

And in fairness, we were constrained in those days by limited memory, 4K base 
register issues and relatively slow instruction times. Why waste bytes, 
addressability and cycles just to make sure OS/360 was behaving as advertised?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Friday, December 1, 2017 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LONGPARM

On 30 November 2017 at 22:26, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

>
> >You can *never* pass more than 100 bytes via PARM=. If you want a 
> >longer parameter, you *must* use PARMDD.
> >
> >The interface as seen by the program is the same in both cases: 
> >halfword length followed by data.
>
> What about the ATTACH, XCTL, LINK, and LOAD/CALL macros.  Prior to the 
> innovation of the LONGPARM attribute it was the responsibility of 
> either the parent or child task (not clearly documented which?) to 
> verify PARM length.


There is nothing in the nature of ATTACH, XCTL, LINK or LOAD/CALL that suggests 
the argument(s) must be of the form halfword length followed by data. And 
indeed it's very often the case that internal routines have R1 pointing at some 
quite different data structure. For that matter R1 doesn't have to be a valid 
pointer at all. Any checking/rejection at the system level that assumed this 
kind of argument would cause huge breakage all over the place.


> Do these nowadays respect the NOLONGPARM setting?
>

Clearly not. They have no way of knowing what kind of data the called program 
is expecting.

A defensively coded subroutine should *always* validate its arguments.
>

No argument. (Yeah, I know...)

> It seems OS/360 developers were unaware of this.

I don't know why you say that. I think we've been through this a zillion times 
on this list. Many programs depended on the documented restriction that 
JCL-supplied parms could not exceed 100 bytes. While this may not be
*the* greatest design, it was common. There was no integrity exposure until 
facilities to pass in long parms to a job step program became 

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

Since it's Friday

[Pew, Curtis G]

This is just a curiosity question, but I’ve wondered about this.

The JCL reference says:

All temporary data set names begin as follows: SYSyyddd.Thhmmss.RA000.jjobname

Does anyone know the story behind the ‘RA000’ part? It seems unnecessary and 
arbitrary.

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: LONGPARM

[Tony Harminc]

On 30 November 2017 at 22:26, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

>
> >You can *never* pass more than 100 bytes via PARM=. If you want a longer
> >parameter, you *must* use PARMDD.
> >
> >The interface as seen by the program is the same in both cases: halfword
> >length followed by data.
>
> What about the ATTACH, XCTL, LINK, and LOAD/CALL macros.  Prior to
> the innovation of the LONGPARM attribute it was the responsibility of
> either the parent or child task (not clearly documented which?) to
> verify PARM length.


There is nothing in the nature of ATTACH, XCTL, LINK or LOAD/CALL that
suggests the argument(s) must be of the form halfword length followed by
data. And indeed it's very often the case that internal routines have R1
pointing at some quite different data structure. For that matter R1 doesn't
have to be a valid pointer at all. Any checking/rejection at the system
level that assumed this kind of argument would cause huge breakage all over
the place.


> Do these nowadays respect the NOLONGPARM setting?
>

Clearly not. They have no way of knowing what kind of data the called
program is expecting.

A defensively coded subroutine should *always* validate its arguments.
>

No argument. (Yeah, I know...)

> It seems OS/360 developers were unaware of this.

I don't know why you say that. I think we've been through this a zillion
times on this list. Many programs depended on the documented restriction
that JCL-supplied parms could not exceed 100 bytes. While this may not be
*the* greatest design, it was common. There was no integrity exposure until
facilities to pass in long parms to a job step program became available,
and the "in the wild" exposure wasn't very long (it was fixed between the
time I noticed it and when I got a demo exploit ready to send to IBM...)
GIven that there's still at least one OS/390 user out there, I won't
publish the exploit for another few years. In any case, finding your own is
close to trivial.

Tony H.

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

Re: Passing data from step-to-step in single job using memory??

[Charles Mills]

Back when I was a DOS/360 sysprog, one of the very first product ideas I ever 
had was a memory-resident program-to-program named data passer -- kind of like 
name/token services or environment variables. A caller would have been able to 
set or retrieve values by name. I never followed through. I don't remember the 
details. I guess the values would have been accessible by a called API or a 
utility program.

What's my point? I guess I don't have one. 

What's wrong with name/token services?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, December 1, 2017 10:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Passing data from step-to-step in single job using memory??

Well, I haven't really found a way to do what I would like. I want to pass a 
_small_ amount of data from one step to a subsequent step in a single job. I 
want the data "cleaned up" at end of job automatically.
Historically, this means a temporary PS data set, perhaps in VIO (which is 
memory). I'm just looking to see if there is another way. Why? I guess just 
"for fun(??)."

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

Re: Passing data from step-to-step in single job using memory??

[Tom Marchant]

On Fri, 1 Dec 2017 12:22:41 -0600, John McKown wrote:
>
>​Yeah. My "problem" is not with VIO, but with QSAM. Writing a RENT,REUS
>HLASM program which I want to be AMODE(31),RMODE(ANY) is just a PITA with
>QSAM. I was hoping for an easier API.​

Why a PITA? If you are RENT, you will need to GETMAIN some storage. 
To create a DCB, you will need storage below the line. Big deal. Unless 
your program's storage requirements are large, you could make all of 
your GETMAINed storage below the line.

Can you run both programs in one step? Perhaps the first one calls the 
second, or they are both called by a third program. The third program can 
pass an area for the first to save the info and the second to retrieve it.

-- 
Tom Marchant

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

Re: Passing data from step-to-step in single job using memory??

[Paul Gilmartin]

On Fri, 1 Dec 2017 12:22:41 -0600, John McKown wrote:
>
>​Yeah. My "problem" is not with VIO, but with QSAM. Writing a RENT,REUS
>HLASM program which I want to be AMODE(31),RMODE(ANY) is just a PITA with
>QSAM. I was hoping for an easier API.​
> 
Name-token services?

Batchpipes?

LINK to a QSAM library subroutine, RMODE 24, AMODE ANY with arguments:
o DDNAME
o Read/write flag
o Data length
o Data address

This is oddly similar to the UNIX limitation that a child process can't modify 
the
parent's environment variables.

And the OS feature I miss most in UNIX is temporary data sets.

-- gil

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

Re: Passing data from step-to-step in single job using memory??

[John McKown]

On Fri, Dec 1, 2017 at 12:19 PM, Steve Thompson  wrote:

> On 12/01/2017 01:08 PM, John McKown wrote:
>
>> Well, I haven't really found a way to do what I would like. I want to pass
>> a _small_ amount of data from one step to a subsequent step in a single
>> job. I want the data "cleaned up" at end of job automatically.
>> Historically, this means a temporary PS data set, perhaps in VIO (which is
>> memory). I'm just looking to see if there is another way. Why? I guess
>> just
>> "for fun(??)."
>>
>>
> Once upon a time during VSE to MVS type migrations, Cortex (back when I
> was working with CTG) had a COMREG equivalent for MVS and one could pass
> data (limited amount) between "steps".
>
> Trust me, VIO is much better (in my opinion), because you don't have to
> have an APF program...
>

​Yeah. My "problem" is not with VIO, but with QSAM. Writing a RENT,REUS
HLASM program which I want to be AMODE(31),RMODE(ANY) is just a PITA with
QSAM. I was hoping for an easier API.​



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



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Passing data from step-to-step in single job using memory??

[Steve Thompson]

On 12/01/2017 01:08 PM, John McKown wrote:

Well, I haven't really found a way to do what I would like. I want to pass
a _small_ amount of data from one step to a subsequent step in a single
job. I want the data "cleaned up" at end of job automatically.
Historically, this means a temporary PS data set, perhaps in VIO (which is
memory). I'm just looking to see if there is another way. Why? I guess just
"for fun(??)."



Once upon a time during VSE to MVS type migrations, Cortex (back 
when I was working with CTG) had a COMREG equivalent for MVS and 
one could pass data (limited amount) between "steps".


Trust me, VIO is much better (in my opinion), because you don't 
have to have an APF program...


Regards,
Steve Thompson

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

Re: Problem after starting PPRC

[Carmen Vitullo]

ICKDSF 


https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.antg000/gr078.htm
 


Carmen Vitullo 

- Original Message -

From: "גדי בן אבי"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, December 1, 2017 11:10:52 AM 
Subject: Re: Problem after starting PPRC 

The CSUSPEND command is exactly what I need. 
How do I issue it? Under TSO, some other way? 

Gadi 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab 
Sent: Friday, December 1, 2017 1:30 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Problem after starting PPRC 

On Thu, Nov 30, 2017 at 6:22 AM, גדי בן אבי  wrote: 
> Hi, 
> 
> Yesterday we established PPRC (Global Mirror) relationships between our local 
> DS8884 and our remote DS8884. 
> This is our first venture into the storage replication area. 
> 
> We have a series of jobs that use flashcopy to copy a volume to a secondary 
> volume, and then backu to secondary to tape. This is done using DFSMSdss. 
> The command looks like this: 
> COPY FULL ADMINISTRATOR INDYNAM(SCR016) OUTDYNAM(FLSH04) - 
> DUMPCONDITIONING FASTREPLICATION(REQUIRED) PURGE ALLDATA(*) - ALLEXCP 
> CANCELERROR IF LASTCC = 0 THEN DUMP FULL ADMIN INDYNAM(FLSH04) 
> OUTDDNAME(OUTPUT) ALLDATA(*) - ALLEXCP OPTIMIZE(4) CANCELERROR 
> 
> ADR918I (001)-DDTFP(03), FAST REPLICATION COULD NOT BE USED FOR VOLUME 
> SCR016, RETURN CODE 9 

This indicates the source volume SCR016 is in a PPRC pair. 
To make the backup copy, SUSPEND the PPRC relationship (updates to remote 
volume are stopped but updated tracks are being tracked), make your copy, then 
RESUME the PPRC relationship (and updated tracks will be sent). 

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.antg000/susvlpr.htm
 

-- 
Mike A Schwab, Springfield IL USA 
Where do Forest Rangers go to get away from it all? 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal. 

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

Passing data from step-to-step in single job using memory??

[John McKown]

Well, I haven't really found a way to do what I would like. I want to pass
a _small_ amount of data from one step to a subsequent step in a single
job. I want the data "cleaned up" at end of job automatically.
Historically, this means a temporary PS data set, perhaps in VIO (which is
memory). I'm just looking to see if there is another way. Why? I guess just
"for fun(??)."

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: IBM does what IBM does best: Raises the chopper again

[Steve Thompson]

Since it is Friday, and all

https://www.youtube.com/watch?v=9Gc4QTqslN4

On 12/01/2017 12:50 PM, Elardus Engelbrecht wrote:

Stone, Marshall wrote:


HEX 42 in Binary - 0100 0010  - now using fingers up/down to represent digits...


Hmmm, it is looking to me like two middle fingers. Careful fella, you don't mess around 
with the ancient art of raising the middle finger, aka "the bird"...

;-D ;-D ;-D

Groete / Greetings
Elardus Engelbrecht

--
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: IBM does what IBM does best: Raises the chopper again

[Elardus Engelbrecht]

Stone, Marshall wrote:

>HEX 42 in Binary - 0100 0010  - now using fingers up/down to represent 
>digits...

Hmmm, it is looking to me like two middle fingers. Careful fella, you don't 
mess around with the ancient art of raising the middle finger, aka "the bird"...

;-D ;-D ;-D

Groete / Greetings
Elardus Engelbrecht

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

Re: The next generation calculator - or not

[Elardus Engelbrecht]

Dyck, Lionel B. wrote:

>https://www.youtube.com/watch?v=RXJKdh1KZ0w
>I'm sure a lot of PHB's will be buying this before the end of the year.

Indeed, these PHB's really like that new toy with all of the fancy technobabble 
spoken by that guy in that funny vid.

Have fun, this is indeed Friday! The last Friday I got was in last month! I 
just can't win

Oh, you can buy that thing only on 1 April any year!

Groete / Greetings
Elardus Engelbrecht

PS: If you want some serious sanity checks - look at 
https://en.wikipedia.org/wiki/Turboencabulator 

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

Re: IBM does what IBM does best: Raises the chopper again

[Tom Brennan]

Now that's deep :)
Lucky my daughter wasn't around when I followed the instructions.

Stone, Marshall wrote:

HEX 42 in Binary - 0100 0010  - now using fingers up/down to represent digits...

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Friday, December 01, 2017 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: IBM does what IBM does best: Raises the chopper again

And check out the first two religious meanings for 42:  In Japanese, 
pronouncing the two digits is the same as the word for death.  In Egypt, 42 
questions are asked of a dead person.
https://en.wikipedia.org/wiki/42_(number)#Religion

On Thu, Nov 30, 2017 at 8:59 AM, Jack J. Woehr  wrote:


On 11/30/2017 2:47 AM, Edward Gould wrote:


I know I shouldn’t ask but what is “42”.



The Answer to Life, the Universe, and Everything, as revealed by Deep
Thought in Douglas Adams's _Hitchhiker's Guide to the Galaxy_.

Another computer was then built to discover what indeed is the
Question to Life, the Universe, and Everything.

"Computers are useless, they can only give you answers." - Pablo
Picasso

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the
universe www.softwoehr.com # with a fine understanding of human
fallibility. - Carl Sagan

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





--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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 may be CONFIDENTIAL and is for the 
intended addressee only. Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited. If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

--
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: IBM does what IBM does best: Raises the chopper again

[Pommier, Rex]

The number of employees left at IBM in 5 years in the United States?  :-)>   
FTFY.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dale R. Smith
Sent: Friday, December 01, 2017 10:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM does what IBM does best: Raises the chopper again

On Thu, 30 Nov 2017 03:47:51 -0600, Edward Gould  
wrote:

>> On Nov 30, 2017, at 1:23 AM, Jack J. Woehr  wrote:
>> 
>> “42"
>
>I know I shouldn’t ask but what is “42”.
>
>Ed

The number of employees left at IBM in 5 years?  :-)>

-- 
Dale R. Smith

--
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: Consolidate Consoles

[Jim Beck]

We use Attachmate's InfoConnect on a Windows 7 PC, which allows multiple 
sessions within a single window.  Each LPAR has a primary and alternate ICC 
consoles defined.  The PC has each primary console active in the one window 
always up whenever the PC is up.

Jim

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

Re: Problem after starting PPRC

[גדי בן אבי]

The CSUSPEND command is exactly what I need.
How do I issue it? Under TSO, some other way?

Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Friday, December 1, 2017 1:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problem after starting PPRC

On Thu, Nov 30, 2017 at 6:22 AM, גדי בן אבי  wrote:
> Hi,
>
> Yesterday we established PPRC (Global Mirror) relationships between our local 
> DS8884 and our remote DS8884.
> This is our first venture into the storage replication area.
>
> We have a series of jobs that use flashcopy to copy a volume to a secondary 
> volume, and then backu to secondary to tape. This is done using DFSMSdss.
> The command looks like this:
> COPY FULL ADMINISTRATOR INDYNAM(SCR016) OUTDYNAM(FLSH04) -
> DUMPCONDITIONING FASTREPLICATION(REQUIRED) PURGE ALLDATA(*) -  ALLEXCP
> CANCELERROR  IF LASTCC = 0 THEN  DUMP FULL ADMIN INDYNAM(FLSH04)
> OUTDDNAME(OUTPUT) ALLDATA(*) - ALLEXCP OPTIMIZE(4) CANCELERROR
>
> ADR918I (001)-DDTFP(03), FAST REPLICATION COULD NOT BE USED FOR VOLUME
> SCR016, RETURN CODE 9

This indicates the source volume SCR016 is in a PPRC pair.
To make the backup copy, SUSPEND the PPRC relationship (updates to remote 
volume are stopped but updated tracks are being tracked), make your copy, then 
RESUME the PPRC relationship (and updated tracks will be sent).

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.antg000/susvlpr.htm

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

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

Re: LMDLIST GROUP option question - How to change/override UNIT(SYSDA)?

[Chris Bowen]

The OP has a satisfactory solution for his problem.

However, for the record, it somewhat resembles a problem we experienced 
recently.

For new-ish TSO users ISPF allocated datasets started turning up on volumes 
where they were not wanted. (More comprehensive SMS management is something I 
hope that we will get to one day.)

Anyway, the colleague who resolved the issue reported that  "In RACF old users 
had UNIT for TSO set as SYSDA while newer users have UNIT set as SYSALLDA."

At this point I should mention that I'm _not_ a RACF person.

Perhaps this might be useful to somebody searching the archives in the future.

Chris Bowen
Macro 4 
A Division of Unicom Global

-Original Message-
Date:Thu, 30 Nov 2017 18:03:39 +
From:"Farley, Peter x23353" 
Subject: LMDLIST GROUP option question - How to change/override UNIT(SYSDA)?

Hi All,

I am using the LMDLIST service with the GROUP option in ISPF to save a list of 
certain datasets.  The GROUP option saves the list to a dataset with name 
&PREFIX.group-value.DATASETS, but it uses UNIT(SYSDA) to create this dataset.

Is there a way to change the UNIT used by ISPF LMDLIST to a different esoteric 
unit value?  SYSDA here allocates to a storage pool on WORKxx volumes where 
datasets are deleted  in a very short time (usually just a few minutes, 
sometimes less).  We programmers use a different unit esoteric to create 
permanent datasets in a different storage pool, and I need LMDLIST to use that 
testing unit esoteric in place of SYSDA.

TIA for any help or RTFM you can provide.

Peter

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

Re: IBM does what IBM does best: Raises the chopper again

[Stone, Marshall]

HEX 42 in Binary - 0100 0010  - now using fingers up/down to represent digits...

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Friday, December 01, 2017 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: IBM does what IBM does best: Raises the chopper again

And check out the first two religious meanings for 42:  In Japanese, 
pronouncing the two digits is the same as the word for death.  In Egypt, 42 
questions are asked of a dead person.
https://en.wikipedia.org/wiki/42_(number)#Religion

On Thu, Nov 30, 2017 at 8:59 AM, Jack J. Woehr  wrote:
> On 11/30/2017 2:47 AM, Edward Gould wrote:
>>
>> I know I shouldn’t ask but what is “42”.
>
>
> The Answer to Life, the Universe, and Everything, as revealed by Deep
> Thought in Douglas Adams's _Hitchhiker's Guide to the Galaxy_.
>
> Another computer was then built to discover what indeed is the
> Question to Life, the Universe, and Everything.
>
> "Computers are useless, they can only give you answers." - Pablo
> Picasso
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe www.softwoehr.com # with a fine understanding of human
> fallibility. - Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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 may be CONFIDENTIAL and is for the 
intended addressee only. Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited. If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

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

Re: IBM does what IBM does best: Raises the chopper again

[Dale R. Smith]

On Thu, 30 Nov 2017 03:47:51 -0600, Edward Gould  
wrote:

>> On Nov 30, 2017, at 1:23 AM, Jack J. Woehr  wrote:
>> 
>> “42"
>
>I know I shouldn’t ask but what is “42”.
>
>Ed

The number of employees left at IBM in 5 years?  :-)>

-- 
Dale R. Smith

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

Re: LONGPARM

[Charles Mills]

@Gil, there are two issues:

There is no *integrity* exposure (at least in theory) from long parms and CALL, 
XCTL, etc. Either both programs are loaded from an APF-authorized library (in 
which case we are forced to assume honesty and competence on the part of the 
authors*) or else the called program is certainly not running authorized, so 
while a longer than expected PARM might cause a S0Cx, it cannot affect the 
integrity of the system as a whole. In other words, it can overlay program 
storage but not system storage.

*Laugh if you want, but if you don't make that assumption then all of MVS 
integrity goes down the drain.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, November 30, 2017 7:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LONGPARM

On Thu, 30 Nov 2017 18:40:01 -0800, Ed Jaffe wrote:

>On 11/30/2017 4:32 PM, Charles Mills wrote:
>> Thanks.
>>
>> Got it. In order for a program to be passed > 100 bytes from // EXEC it must 
>> be either not authorized or linked with LONGPARM (or both).
>>
>> Am I right on bullet one? Parms greater than 100 bytes are a PARMDD thing 
>> only, never a PARM= thing?
>
>You can *never* pass more than 100 bytes via PARM=. If you want a 
>longer parameter, you *must* use PARMDD.
>
>The interface as seen by the program is the same in both cases: 
>halfword length followed by data.
>
What about the ATTACH, XCTL, LINK, and LOAD/CALL macros.  Prior to the 
innovation of the LONGPARM attribute it was the responsibility of either the 
parent or child task (not clearly documented which?) to verify PARM length.  Do 
these nowadays respect the NOLONGPARM setting?

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

Re: IBM does what IBM does best: Raises the chopper again

[Mike Schwab]

And check out the first two religious meanings for 42:  In Japanese,
pronouncing the two digits is the same as the word for death.  In
Egypt, 42 questions are asked of a dead person.
https://en.wikipedia.org/wiki/42_(number)#Religion

On Thu, Nov 30, 2017 at 8:59 AM, Jack J. Woehr  wrote:
> On 11/30/2017 2:47 AM, Edward Gould wrote:
>>
>> I know I shouldn’t ask but what is “42”.
>
>
> The Answer to Life, the Universe, and Everything, as revealed by Deep
> Thought in Douglas Adams's _Hitchhiker's Guide to the Galaxy_.
>
> Another computer was then built to discover what indeed is the Question to
> Life, the Universe, and Everything.
>
> "Computers are useless, they can only give you answers." - Pablo Picasso
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. - Carl
> Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: The next generation calculator - or not

[Grinsell, Don]

I want to know how he kept a straight face through all that.  Thanks.

--
 
Donald Grinsell, Systems Programmer
Enterprise Technology Services Bureau
SITSD/Montana Department of Administration
406.444.2983 (D)


"We can't solve problems by using the same kind of thinking we used when we 
created them."
~ Albert Einstein

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dyck, Lionel B. (TRA)
> Sent: Friday, December 01, 2017 8:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: The next generation calculator - or not
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.
> com%2Fwatch%3Fv%3DRXJKdh1KZ0w&data=02%7C01%7Cdgrinsell%40MT.GOV%7C479794e481c
> 34f76888008d538d43b01%7C07a94c98f30f4abbbd7ed63f8720dc02%7C0%7C0%7C6364774065
> 36519206&sdata=dUCnjBTtKdLdSaeXSE0gFUKnehpAQ81HFDuXUS972fY%3D&reserved=0
> 
> I'm sure a lot of PHB's will be buying this before the end of the year.
> 
> --
> Lionel B. Dyck <
> Mainframe Systems Programmer - TRA
> 
> --
> 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: LONGPARM

[Maxim Bochagov]

Hello All,

What about to check the existence of a PARM DD-name before the fetch
of inline params?
Like, if you want to pass a long parlist and it is more than 100
bytes, then just specify a //PARM DD * card before this mind flow.
Anycase, this way is a LOCAL FIX for this problem, IMHO..

=Maxim

2017-12-01 18:27 GMT+03:00 Ed Jaffe :
> On 11/30/2017 9:10 PM, Paul Gilmartin wrote:
>>
>> On Thu, 30 Nov 2017 20:43:17 -0800, Ed Jaffe wrote:
>>
>>>
>>> LONGPARM isn't used other than during initial establishment of an APF
>>> authorized job step.
>>>
>> "LONGPARM isn't used ..." has confusing semantics.  That would seem to
>> imply
>> that in other contexts the 100-character limit is enforced.  Or in those
>> other cases,
>> is LONGPARM presumed?
>
>
> LONGPARM allows parms > 100 bytes to be passed to authorized programs
> invoked via JCL // EXEC statement. Nothing confusing about that.
>
> Stated another way: if your program is bound with AC(1) and loaded from an
> APF authorized concatenation, you will need LONGPARM if you wish to receive
> parms > 100 bytes. Without LONGPARM, your program will only be allowed to
> receive parms <= 100 bytes.
>
> Programs invoked through other means (ATTACH, etc) and unauthorized programs
> invoked via JCL // EXEC statement can receive long parms as well.
>
> It's just that simple...
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Regards,
=Maxim Bochagov

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

The next generation calculator - or not

[Dyck, Lionel B. (TRA)]

https://www.youtube.com/watch?v=RXJKdh1KZ0w

I'm sure a lot of PHB's will be buying this before the end of the year.

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA

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

Re: Finding OMVS Files with Owner IDs for Deleted Owners?

[Dyck, Lionel B. (TRA)]

Thank you - that is just what I need.

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Styles, Andy (ITS zPlatform Services)
Sent: Friday, December 01, 2017 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Finding OMVS Files with Owner IDs for Deleted Owners?

Classification: Public
Assuming their id has been deleted:

find . -nouser

-rw-r--r--1 5  10 Jul 17 09:09 test.txt

Where '5' is the id of the deleted user (actually just me issuing chown 5 
test.txt - but users without ids show up as numerics in ls).

01/12/17 15:45:50 /u/xxx $ find . -nouser 
./test.txt

There's a -nogroup equivalent too. 

Andy Styles
z/Series Systems Programmer

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: 01 December 2017 15:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Finding OMVS Files with Owner IDs for Deleted Owners?

-- This email has reached the Bank via an external source --
 

Is there a tool that can find and report out all files that are owned by users 
who have departed?

Just ran into a few that were owned by someone who left several years ago.

Thank you

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


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



Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555.

Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. 
Registered in England and Wales no. 2065. Telephone 0207626 1500.

Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC327000. Telephone: 03457 801 801.

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
Regulation Authority and regulated by the Financial Conduct Authority and 
Prudential Regulation Authority.

Halifax is a division of Bank of Scotland plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.

--
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: Finding OMVS Files with Owner IDs for Deleted Owners?

[John McKown]

On Fri, Dec 1, 2017 at 9:32 AM, Dyck, Lionel B. (TRA) 
wrote:

> Is there a tool that can find and report out all files that are owned by
> users who have departed?
>
> Just ran into a few that were owned by someone who left several years ago.
>

​The UNIX "find" command can do that for you. But it can take a long while
to run, depending on where you start from. E.g. if you start the scan at
the root directory, it will traverse every directory in every mounted
filesystem (in general). This will take a while. In z/OS BATCH, you can try:

//SCANIT EXEC PGM=BPXBATCH,REGION=0M,
// PARM='SH find / -nouser'
//STDIN DD PATH='/dev/null'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//

​Basically the "-nouser" switch does exactly what you want. For each file
it finds (all in the above case), it will only display those whose "owner"
UID does not have an associated RACF ID.​



> Thank you
>
> --
> Lionel B. Dyck <
> Mainframe Systems Programmer - TRA
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Finding OMVS Files with Owner IDs for Deleted Owners?

[Styles, Andy (ITS zPlatform Services)]

Classification: Public
Assuming their id has been deleted:

find . -nouser

-rw-r--r--1 5  10 Jul 17 09:09 test.txt

Where '5' is the id of the deleted user (actually just me issuing chown 5 
test.txt - but users without ids show up as numerics in ls).

01/12/17 15:45:50 /u/xxx $ find . -nouser 
./test.txt

There's a -nogroup equivalent too. 

Andy Styles
z/Series Systems Programmer

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: 01 December 2017 15:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Finding OMVS Files with Owner IDs for Deleted Owners?

-- This email has reached the Bank via an external source --
 

Is there a tool that can find and report out all files that are owned by users 
who have departed?

Just ran into a few that were owned by someone who left several years ago.

Thank you

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


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



Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555.

Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. 
Registered in England and Wales no. 2065. Telephone 0207626 1500.

Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC327000. Telephone: 03457 801 801.

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
Regulation Authority and regulated by the Financial Conduct Authority and 
Prudential Regulation Authority.

Halifax is a division of Bank of Scotland plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.

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

Finding OMVS Files with Owner IDs for Deleted Owners?

[Dyck, Lionel B. (TRA)]

Is there a tool that can find and report out all files that are owned by users 
who have departed?

Just ran into a few that were owned by someone who left several years ago.

Thank you

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


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

Re: LONGPARM

[Ed Jaffe]

On 11/30/2017 9:10 PM, Paul Gilmartin wrote:

On Thu, 30 Nov 2017 20:43:17 -0800, Ed Jaffe wrote:



LONGPARM isn't used other than during initial establishment of an APF
authorized job step.


"LONGPARM isn't used ..." has confusing semantics.  That would seem to imply
that in other contexts the 100-character limit is enforced.  Or in those other 
cases,
is LONGPARM presumed?


LONGPARM allows parms > 100 bytes to be passed to authorized programs 
invoked via JCL // EXEC statement. Nothing confusing about that.


Stated another way: if your program is bound with AC(1) and loaded from 
an APF authorized concatenation, you will need LONGPARM if you wish to 
receive parms > 100 bytes. Without LONGPARM, your program will only be 
allowed to receive parms <= 100 bytes.


Programs invoked through other means (ATTACH, etc) and unauthorized 
programs invoked via JCL // EXEC statement can receive long parms as well.


It's just that simple...

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

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

Releasing version 5.0.0 of PDSEGEN - the open source solution for working with PDSE Version 2 Member Generations

[Dyck, Lionel B. (TRA)]

If you are curious about IBM's PDSE Version 2 Member Generations and frustrated 
in using them because the native IBM ISPF doesn't make it easy then check out 
the open source PDSEGEN.  Documentation is available in PDF, DOCX (so you can 
customize for your site), EPUB, and MOBI and now there is a new Reference Card 
available (you have to print it).



It is available from www.lbdsoftwware.com and soon 
from File 312 at www.cbttape.org



If you've been using PDSEGEN then this is an update that you'll want to check 
out.



Version 5.0.0 is here - a big jump from 4.5.1.



Lots of improvements and changes including support 'industry standards'

in the user interface.



See the list of changes below (or in the $CHANGES member of the

distribution PDS).



Be aware of the changes to several line selections:

C is now Copy to another dataset (new)

Z is now Compare (was C)

R is now Rename(was N)

G is now Recover (was R)



There are now two new member display panels that support an expanded

line selection field. This allows line selection commands like COMPare

instead of single character options. Just scroll left or right to find

the new panels. There is one for 2 digit year and one for 4 digit year.



Another change is to the PDSEGENS (site customization defaults) to

define the default member display panel and an option to enable or

disable the display of the changes tutorial panel (PDSEGHCG) when

PDSEGEN detects that a new version/release has been installed. The

default is to display the changes tutorial so that the user knows what

has changed but the site can turn that off. The user can also enable

or disable it using the SET dialog.


--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


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

Re: Problem after starting PPRC

[Pommier, Rex]

Mike,

Actually, not quite.  :-)

The ADR918I message is saying that the target is a source in a PPRC 
relationship.  The message text is slightly misleading since it shows the 
source vol-ser.  The problem is that FLSH04 got set up as a PPRC source to the 
remote machine.  By default, FlashCopy doesn't allow a PPRC source volume to be 
a F/C target.  

The actual text from the x'9' return code says " One or more target devices are 
not eligible for fast replication at this time."

I ran into this exact issue a year ago when we set up our replication.  We just 
removed our flashcopy target volumes from the disk pool that gets replicated.  
In our case, it was temporary use dataset level flash copies, which I think is 
what Gadi is trying to do, flash the volumes long enough to back them up to 
tape then throw away the backup disk copies.  No need to replicate this data to 
the remote device.

Rex


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Friday, December 01, 2017 5:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problem after starting PPRC

On Thu, Nov 30, 2017 at 6:22 AM, גדי בן אבי  wrote:
> Hi,
>
> Yesterday we established PPRC (Global Mirror) relationships between our local 
> DS8884 and our remote DS8884.
> This is our first venture into the storage replication area.
>
> We have a series of jobs that use flashcopy to copy a volume to a secondary 
> volume, and then backu to secondary to tape. This is done using DFSMSdss.
> The command looks like this:
> COPY FULL ADMINISTRATOR INDYNAM(SCR016) OUTDYNAM(FLSH04) -
>  DUMPCONDITIONING FASTREPLICATION(REQUIRED) PURGE ALLDATA(*) -
>  ALLEXCP CANCELERROR
>  IF LASTCC = 0 THEN
>  DUMP FULL ADMIN INDYNAM(FLSH04) OUTDDNAME(OUTPUT) ALLDATA(*) -
> ALLEXCP OPTIMIZE(4) CANCELERROR
>
> ADR918I (001)-DDTFP(03), FAST REPLICATION COULD NOT BE USED FOR VOLUME 
> SCR016, RETURN CODE 9

This indicates the source volume SCR016 is in a PPRC pair.
To make the backup copy, SUSPEND the PPRC relationship (updates to
remote volume are stopped but updated tracks are being tracked), make
your copy, then RESUME the PPRC relationship (and updated tracks will
be sent).

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.antg000/susvlpr.htm

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

[Tom Marchant]

On Thu, 30 Nov 2017 23:10:49 -0600, Paul Gilmartin wrote:

>On Thu, 30 Nov 2017 20:43:17 -0800, Ed Jaffe wrote:
>
>>PARM= and PARMDD are JCL constructs only.
>>
>>LONGPARM isn't used other than during initial establishment of an APF
>>authorized job step.
>> 
>"LONGPARM isn't used ..." has confusing semantics.  That would seem to imply
>that in other contexts the 100-character limit is enforced.  Or in those other 
>cases,
>is LONGPARM presumed?

The LONGPARM attribute on a load module (or program object) is only checked 
during the initial establishment of an APF authorized job step.

What do you think "the 100-character limit is enforced" would mean for ATTACH, 
LINK, XCTL, CALL, etc.? When a program calls another, the calling program 
creates the parameter list. When the initiator ATTACHes a program, the 
initiator 
uses PARM or PARMDD to set the parameter list, and it does so with the limits 
that were discussed.

-- 
Tom Marchant

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

AW: Re: LONGPARM

[Peter Hunkeler]

>"LONGPARM isn't used ..." has confusing semantics.  That would seem to imply 
>that in other contexts the 100-character limit is enforced.  Or in those other 
>cases, is LONGPARM presumed?


You made me curious, so I went to RTFM. I will submit an RCF, because the 
documentation couldn't be more fuzzy and confusing, IMHO. Before submitting, I 
would like to get your opinion on my comments below.


o The Binder manual talks about: "The system checks ... and the program is APF 
authorized."
A program is not APF authorized, the job step TCB is or is not.


o The JCL Reference manual talks about: "If the program to be invoked is from 
an APF authorized library *or* has been bound with the AC(1) attribute..."
The *or* is confusing.


LONPARM is not mentioned with the LINK or ATTACH service. This makes sense and 
indicates to me that it is the *initiator* doing this verification when it 
prepares to attach the program.
So the binder and JCL manuals should say that "The system will check at job 
step initiation when the job step will be set APF authorized


--
Peter Hunkeler



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

Re: Problem after starting PPRC

[Mike Schwab]

On Thu, Nov 30, 2017 at 6:22 AM, גדי בן אבי  wrote:
> Hi,
>
> Yesterday we established PPRC (Global Mirror) relationships between our local 
> DS8884 and our remote DS8884.
> This is our first venture into the storage replication area.
>
> We have a series of jobs that use flashcopy to copy a volume to a secondary 
> volume, and then backu to secondary to tape. This is done using DFSMSdss.
> The command looks like this:
> COPY FULL ADMINISTRATOR INDYNAM(SCR016) OUTDYNAM(FLSH04) -
>  DUMPCONDITIONING FASTREPLICATION(REQUIRED) PURGE ALLDATA(*) -
>  ALLEXCP CANCELERROR
>  IF LASTCC = 0 THEN
>  DUMP FULL ADMIN INDYNAM(FLSH04) OUTDDNAME(OUTPUT) ALLDATA(*) -
> ALLEXCP OPTIMIZE(4) CANCELERROR
>
> ADR918I (001)-DDTFP(03), FAST REPLICATION COULD NOT BE USED FOR VOLUME 
> SCR016, RETURN CODE 9

This indicates the source volume SCR016 is in a PPRC pair.
To make the backup copy, SUSPEND the PPRC relationship (updates to
remote volume are stopped but updated tracks are being tracked), make
your copy, then RESUME the PPRC relationship (and updated tracks will
be sent).

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.antg000/susvlpr.htm

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: SAS - DB2 conversion to Java

[David Crayford]

On 1/12/2017 2:21 AM, Frank Swarbrick wrote:

I have a heavy, perhaps unjustified prejudice, against Java and the JVM.


I used to feel that way. I still don't like Java the language very much 
but I've learned to love the JVM.



I like "native compiled" languages, and I am very happy that IBM is looking to 
have Swift as another native compiled language on z/OS.


Agreed. There's anecdotal evidence that IBM are working on a z/OS port 
of Googles Go language to add to Node.js and Swift. Kotlin can run 
native as well compiled using the same LLVM backend that Swift uses. IBM 
would need to open up LLVM to make that possible on z/OS.


Swift on z/OS seems to be targeted for web apps using the Kitura 
framework utilizing the seamless interop with traditional z/OS languages 
to modernize legacy applications.



That being said, I know nothing about Kotlin other than what I read yesterday after 
seeing your original message.  Since Kotlin does run on a JVM, shouldn't it already 
"just work" on z/OS?


All JVM languages run well on z/OS with a few tweaks.



From: IBM Mainframe Discussion List  on behalf of David 
Crayford 
Sent: Wednesday, November 29, 2017 7:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SAS - DB2 conversion to Java

On 30/11/2017 9:11 AM, Frank Swarbrick wrote:

I've never heard of Kotlin, but it seems to me that Android would be better off 
supporting Swift before it goes another direction.  Or does it already support 
Swift?

The three supported programming languages on Android are Java, Kotlin
and C/C++ for native code. Android runs Googles Dalvik JVM so it
requires a JVM language. For z/OS I would choose Kotlin over Swift any
day of the week. It's a no brainer really, it can access the gargantuan
Java eco-system and it runs on a zIIP. The languages are very similar
http://nilhcem.com/swift-is-like-kotlin/.



From: IBM Mainframe Discussion List  on behalf of David 
Crayford 
Sent: Tuesday, November 28, 2017 7:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SAS - DB2 conversion to Java

On 29/11/2017 8:00 AM, Andrew Rowley wrote:

- I think the reporting is SQL based? SMF data was not designed to be
queried using SQL. I have been down that path. On the other hand, Java
classes are beautiful for working with SMF data (not quite as nice as
C# but still very good).

If you like C# you should take a look at Kotlin, which is even better
and runs on the JVM. It's quickly becoming the language of choice for
Android developers which is no surprise giving it's similarities to
Swift
https://android-developers.googleblog.com/2017/05/android-announces-support-for-kotlin.html.

Java doesn't feel like a new language. It lacks features introduced in
other languages over a decade ago. Java 10 introduces type inference but
it's too little too late. Check out Kotlins Nullable feature. No more
NullPointerExceptions, yay! data classes, properties, a really powerful
lambda syntax and seamless Java interop make it a joy to program in. The
learning curve for Java programmers is small. It took me a couple of
days which is significantly less then the far more complex Scala which I
have yet to completely master.

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