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:[email protected]] On Behalf 
Of John McKown
Sent: Friday, December 1, 2017 3:55 PM
To: [email protected]
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 <
[email protected]> 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. <ouch>​



>
> 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 [email protected] with the message: INFO IBM-MAIN

Reply via email to