Discussion:
Passing data from step-to-step in single job using memory??
Add Reply
John McKown
2017-12-01 18:07:18 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Thompson
2017-12-01 18:18:16 UTC
Reply
Permalink
Raw Message
Post by 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(??)."
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-12-01 18:21:27 UTC
Reply
Permalink
Raw Message
Post by 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(??)."
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-12-01 19:19:31 UTC
Reply
Permalink
Raw Message
Post by John McKown
​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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-12-01 20:53:57 UTC
Reply
Permalink
Raw Message
On Fri, Dec 1, 2017 at 1:20 PM, Paul Gilmartin <
Post by Paul Gilmartin
Post by John McKown
​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.​
Post by Paul Gilmartin
Batchpipes?
​Don't own it.​
Post by Paul Gilmartin
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).​
Post by Paul Gilmartin
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>​
Post by Paul Gilmartin
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.​
Post by Paul Gilmartin
-- 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-12-01 21:04:59 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: Friday, December 1, 2017 3:55 PM
To: IBM-***@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 <
Post by Paul Gilmartin
Post by John McKown
​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.​
Post by Paul Gilmartin
Batchpipes?
​Don't own it.​
Post by Paul Gilmartin
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).​
Post by Paul Gilmartin
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>​
Post by Paul Gilmartin
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.​
Post by Paul Gilmartin
-- 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-12-01 19:39:35 UTC
Reply
Permalink
Raw Message
Post by John McKown
​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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-12-01 21:07:53 UTC
Reply
Permalink
Raw Message
On Fri, Dec 1, 2017 at 1:40 PM, Tom Marchant <
Post by Tom Marchant
Post by John McKown
​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.​
Post by Tom Marchant
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'FFFF' 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.
Post by Tom Marchant
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2017-12-03 09:16:18 UTC
Reply
Permalink
Raw Message
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.
What specifically are you trying to achieve so that you need to use BPX1EXM and cannot use BPX1EXC? The latter can invoke a load module residing in a load library or LPA via external link. All the UNIXish features like passing arguments, environment variables, open files descriptors are availeble.


--
Peter Hunkeler


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-12-03 19:26:24 UTC
Reply
Permalink
Raw Message
Post by John McKown
Post by John McKown
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.
What specifically are you trying to achieve so that you need to use
BPX1EXM and cannot use BPX1EXC? The latter can invoke a load module
residing in a load library or LPA via external link. All the UNIXish
features like passing arguments, environment variables, open files
descriptors are availeble.
​I don't have an actual program or system which I'm trying to write. I am
not doing much during "Open Enrollment" and so I'm just looking at some of
the various z/OS MVs & z/OS UNIX facilities with which I am not really
familiar. In this thread, that is the BPX1EXM callable UNIX service. Why
did I choose this? No real reason. Why am I curious about in-memory data
passing (in this or other environments)? I just am. IOW, this entire thread
is just for my learning. Even a 65 - 1 fortnight, I still like to learn new
stuff.

Basically what I've learned in this thread, at least so far, is that the
only thing I can pass to the invoked program is the equivalent of the data
which can come in via the PARM= on a JCL EXEC PGM=, and in that same
format. From the doc on BPX1EXM, that is, at most, 4096 bytes.​
Post by John McKown
--
Peter Hunkeler
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-12-01 19:53:29 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: Friday, December 1, 2017 10:08 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-12-01 21:48:34 UTC
Reply
Permalink
Raw Message
Post by John McKown
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'FFFF' 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-12-01 21:58:22 UTC
Reply
Permalink
Raw Message
On Fri, 1 Dec 2017 15:09:07 -0600, John McKown <
Post by John McKown
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'FFFF' 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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-12-01 22:04:20 UTC
Reply
Permalink
Raw Message
Post by John McKown
Post by Tom Marchant
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.
Post by John McKown
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.
Post by John McKown
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'FFFF' bytes? I'll need to check that out.
Depends. Using Rexx address ATTCHPGM, I've called BPXBATCH with x'FFFF'
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2017-12-03 09:24:56 UTC
Reply
Permalink
Raw Message
Post by Paul Gilmartin
Depends. Using Rexx address ATTCHPGM, I've called BPXBATCH with x'FFFF'
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?
You were calling ASMA90 (HLASM) with an options list (PARM) of X'8000' bytes length?


--
Peter Hunkeler



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-12-03 15:19:08 UTC
Reply
Permalink
Raw Message
Given that an unauthorized user has access only to unauthorized subpools
and that all unauthorized subpools are freed between steps, some less
direct approach would be necessary, involving authorized code putting the
data into some other kind of storage (be that an authorized subpool,
common storage, shared storage, etc) and providing some means by which the
new step could access that. Perhaps z/OS Unix does so. "Normal" MVS would
likely never do that as it could be considered a violation of B1 security
(to the extent that anyone still cares about B1 security), at least for
the case where the subsequent step might be started in a different address
space, such as in a restart scenario.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
J R
2017-12-03 16:19:21 UTC
Reply
Permalink
Raw Message
"z/OS Unix" as opposed to "Normal MVS"

I like that clarification!
Post by Peter Relson
Given that an unauthorized user has access only to unauthorized subpools
and that all unauthorized subpools are freed between steps, some less
direct approach would be necessary, involving authorized code putting the
data into some other kind of storage (be that an authorized subpool,
common storage, shared storage, etc) and providing some means by which the
new step could access that. Perhaps z/OS Unix does so. "Normal" MVS would
likely never do that as it could be considered a violation of B1 security
(to the extent that anyone still cares about B1 security), at least for
the case where the subsequent step might be started in a different address
space, such as in a restart scenario.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
scott Ford
2017-12-03 16:30:06 UTC
Reply
Permalink
Raw Message
I don't think we or IBM should be close minded to passing job step data in memory.
I agree with Peter , we deal with security all the time. I haven't heard of B1, Peter could you share a link? I don't want leave any system open to hacking or whatever the current buzzword is in our vocabulary. But I also see a level of ignorance and over-reaction , because of a perceived .

Scott
Post by J R
"z/OS Unix" as opposed to "Normal MVS"
I like that clarification!
Post by Peter Relson
Given that an unauthorized user has access only to unauthorized subpools
and that all unauthorized subpools are freed between steps, some less
direct approach would be necessary, involving authorized code putting the
data into some other kind of storage (be that an authorized subpool,
common storage, shared storage, etc) and providing some means by which the
new step could access that. Perhaps z/OS Unix does so. "Normal" MVS would
likely never do that as it could be considered a violation of B1 security
(to the extent that anyone still cares about B1 security), at least for
the case where the subsequent step might be started in a different address
space, such as in a restart scenario.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-12-03 17:24:15 UTC
Reply
Permalink
Raw Message
https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#B_–_Mandatory_protection

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of scott Ford
Sent: Sunday, December 3, 2017 8:31 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Passing data from step-to-step in single job using memory??

I don't think we or IBM should be close minded to passing job step data in memory.
I agree with Peter , we deal with security all the time. I haven't heard of B1, Peter could you share a link? I don't want leave any system open to hacking or whatever the current buzzword is in our vocabulary. But I also see a level of ignorance and over-reaction , because of a perceived .

Scott
Post by J R
"z/OS Unix" as opposed to "Normal MVS"
I like that clarification!
Post by Peter Relson
Given that an unauthorized user has access only to unauthorized
subpools and that all unauthorized subpools are freed between steps,
some less direct approach would be necessary, involving authorized
code putting the data into some other kind of storage (be that an
authorized subpool, common storage, shared storage, etc) and
providing some means by which the new step could access that.
Perhaps z/OS Unix does so. "Normal" MVS would likely never do that
as it could be considered a violation of B1 security (to the extent
that anyone still cares about B1 security), at least for the case
where the subsequent step might be started in a different address space, such as in a restart scenario.
Peter Relson
z/OS Core Technology Design
--------------------------------------------------------------------
-- For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
scott Ford
2017-12-03 17:43:17 UTC
Reply
Permalink
Raw Message
Charles,

A big thanks sir..
Scott
Post by Charles Mills
https://en.wikipedia.org/wiki/Trusted_Computer_System_
Evaluation_Criteria#B_–_Mandatory_protection
Charles
-----Original Message-----
Behalf Of scott Ford
Sent: Sunday, December 3, 2017 8:31 AM
Subject: Re: Passing data from step-to-step in single job using memory??
I don't think we or IBM should be close minded to passing job step data in memory.
I agree with Peter , we deal with security all the time. I haven't heard
of B1, Peter could you share a link? I don't want leave any system open to
hacking or whatever the current buzzword is in our vocabulary. But I also
see a level of ignorance and over-reaction , because of a perceived .
Scott
Post by J R
"z/OS Unix" as opposed to "Normal MVS"
I like that clarification!
Post by Peter Relson
Given that an unauthorized user has access only to unauthorized
subpools and that all unauthorized subpools are freed between steps,
some less direct approach would be necessary, involving authorized
code putting the data into some other kind of storage (be that an
authorized subpool, common storage, shared storage, etc) and
providing some means by which the new step could access that.
Perhaps z/OS Unix does so. "Normal" MVS would likely never do that
as it could be considered a violation of B1 security (to the extent
that anyone still cares about B1 security), at least for the case
where the subsequent step might be started in a different address
space, such as in a restart scenario.
Post by J R
Post by Peter Relson
Peter Relson
z/OS Core Technology Design
--------------------------------------------------------------------
-- For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
*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

***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Finnell
2017-12-03 21:03:13 UTC
Reply
Permalink
Raw Message
There were two or three guys active in SHARE that had the CAD(Cloak and dagger) site code. One of their jobs was to evaluate operating systems for 'security'. IIRC only MULTICS was higher than MVS. The evaluations were published, maybe it was a green book. Then on last page "if it's connected to a network these evaluations are null and void."
 
Then they moved to a different standard altogether but kept the basics intact.  
 
In a message dated 12/3/2017 11:25:40 AM Central Standard Time, ***@MCN.ORG writes:

 
https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#B_–_Mandatory_protection

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2017-12-04 04:38:18 UTC
Reply
Permalink
Raw Message
You don't need to be authorized to use z/OS UNIX shared memory segments.
You do need access to the file system and the memory segments are
protected using the normal UNIX permissions. Semaphores and pthread
mutexes can also reside in shared memory for inter-process locking.

The /tmp TFS is backed by memory so the easiest solution may be to us
files in the TFS.
Post by Peter Relson
Given that an unauthorized user has access only to unauthorized subpools
and that all unauthorized subpools are freed between steps, some less
direct approach would be necessary, involving authorized code putting the
data into some other kind of storage (be that an authorized subpool,
common storage, shared storage, etc) and providing some means by which the
new step could access that. Perhaps z/OS Unix does so. "Normal" MVS would
likely never do that as it could be considered a violation of B1 security
(to the extent that anyone still cares about B1 security), at least for
the case where the subsequent step might be started in a different address
space, such as in a restart scenario.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-12-04 14:28:05 UTC
Reply
Permalink
Raw Message
Post by David Crayford
You don't need to be authorized to use z/OS UNIX shared memory segments.
You do need access to the file system and the memory segments are protected
using the normal UNIX permissions. Semaphores and pthread mutexes can also
reside in shared memory for inter-process locking.
The /tmp TFS is backed by memory so the easiest solution may be to us
files in the TFS.
​The only problem that I have ever had with using /tmp is that, if it were
"released" (i.e. documented to & it's use encouraged) to programmers, then
I would run into complaints about "running out" of space on /tmp and file
name collisions. E.g. one job using up all the space in /tmp due to the JCL
writing believing it would just be a few records, but then a "bug" cause it
to try to write millions (this has happened here). ​Also, our programmers
at least, tend to be "lazy" and expect z/OS to "clean up" after them (some
of them don't even CLOSE their data sets). So I would need to manage the
files & directories in /tmp, most likely using skulker. And, of course,
that means that eventually somebody will whine that one of their files got
deleted.

​I have addressed a _UNIX shell user_ using too much "temp" space by making
/tmp2 be an "automount controlled" mount point and forcing all the
"temporary file location" environment variables, such as TMP, TMPDIR, TEMP,
et al., to be /tmp2/&SYSUID. So when a shell user uses a properly coded
shell command, they go into their own zFS filesystem data set.​
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jousma, David
2017-12-04 14:34:08 UTC
Reply
Permalink
Raw Message
Speaking of skulker, I have implemented its use via cron to keep /tmp cleaned up. There are a few files that get written there by some life of IPL started tasks(mostly TCPIP related) that do exceed the time frame skulker is cleaning up, so I created another script that runs prior to skulker that simply does a touch -c to update the date/time stamp of the file if it already exists for a list of "loved files". I didn’t initially create this script as most of the tasks didn’t complain, until we implemented the IOBSNMP extension of SNMP and it writes a dip_socket file there, that if deleted, causes problems for it.

_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: Monday, December 04, 2017 9:29 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Passing data from step-to-step in single job using memory??

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**
Post by David Crayford
You don't need to be authorized to use z/OS UNIX shared memory segments.
You do need access to the file system and the memory segments are
protected using the normal UNIX permissions. Semaphores and pthread
mutexes can also reside in shared memory for inter-process locking.
The /tmp TFS is backed by memory so the easiest solution may be to us
files in the TFS.
​The only problem that I have ever had with using /tmp is that, if it were "released" (i.e. documented to & it's use encouraged) to programmers, then I would run into complaints about "running out" of space on /tmp and file name collisions. E.g. one job using up all the space in /tmp due to the JCL writing believing it would just be a few records, but then a "bug" cause it to try to write millions (this has happened here). ​Also, our programmers at least, tend to be "lazy" and expect z/OS to "clean up" after them (some of them don't even CLOSE their data sets). So I would need to manage the files & directories in /tmp, most likely using skulker. And, of course, that means that eventually somebody will whine that one of their files got deleted.

​I have addressed a _UNIX shell user_ using too much "temp" space by making
/tmp2 be an "automount controlled" mount point and forcing all the "temporary file location" environment variables, such as TMP, TMPDIR, TEMP, et al., to be /tmp2/&SYSUID. So when a shell user uses a properly coded shell command, they go into their own zFS filesystem data set.​


--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2017-12-04 15:06:07 UTC
Reply
Permalink
Raw Message
Then don't use /tmp. Mount a bespoke TFS and manage it accordingly.
Post by John McKown
Post by David Crayford
You don't need to be authorized to use z/OS UNIX shared memory segments.
You do need access to the file system and the memory segments are protected
using the normal UNIX permissions. Semaphores and pthread mutexes can also
reside in shared memory for inter-process locking.
The /tmp TFS is backed by memory so the easiest solution may be to us
files in the TFS.
​The only problem that I have ever had with using /tmp is that, if it were
"released" (i.e. documented to & it's use encouraged) to programmers, then
I would run into complaints about "running out" of space on /tmp and file
name collisions. E.g. one job using up all the space in /tmp due to the JCL
writing believing it would just be a few records, but then a "bug" cause it
to try to write millions (this has happened here). ​Also, our programmers
at least, tend to be "lazy" and expect z/OS to "clean up" after them (some
of them don't even CLOSE their data sets). So I would need to manage the
files & directories in /tmp, most likely using skulker. And, of course,
that means that eventually somebody will whine that one of their files got
deleted.
​I have addressed a _UNIX shell user_ using too much "temp" space by making
/tmp2 be an "automount controlled" mount point and forcing all the
"temporary file location" environment variables, such as TMP, TMPDIR, TEMP,
et al., to be /tmp2/&SYSUID. So when a shell user uses a properly coded
shell command, they go into their own zFS filesystem data set.​
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Kirk Wolf
2017-12-04 15:18:39 UTC
Reply
Permalink
Raw Message
Right. Its often a good idea to set up alternate temp filesystems - either
TFS or ZFS.
The $TMPDIR environment variable can be set to point so that most commands
will use this rather than /tmp.
Use skulker, mount with "FSFULL" and use auto-ops to assist with management.

Here is some documentation on our website for other best practices for
managing temp filesystems on z/OS:
https://dovetail.com/docs/pt-quick-inst/pto-inst-tmp.html

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2017-12-04 16:29:07 UTC
Reply
Permalink
Raw Message
Pipe stepa ! stepb

(No pipe char on my phone)
Post by Kirk Wolf
Right. Its often a good idea to set up alternate temp filesystems - either
TFS or ZFS.
The $TMPDIR environment variable can be set to point so that most commands
will use this rather than /tmp.
Use skulker, mount with "FSFULL" and use auto-ops to assist with management.
Here is some documentation on our website for other best practices for
https://dovetail.com/docs/pt-quick-inst/pto-inst-tmp.html
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-12-03 22:40:15 UTC
Reply
Permalink
Raw Message
Post by Edward Finnell
There were two or three guys active in SHARE that had the CAD(Cloak and dagger) site code. One of their jobs was to evaluate operating systems for 'security'. IIRC only MULTICS was higher than MVS. The evaluations were published, maybe it was a green book. Then on last page "if it's connected to a network these evaluations are null and void."
 
"if it's connected to a network ..." is pretty restrictive nowadays. Perhaps less
so in the heyday of MULTICS.
Post by Edward Finnell
Then they moved to a different standard altogether but kept the basics intact.  
 
 
https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#B_–_Mandatory_protection
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-12-04 12:53:54 UTC
Reply
Permalink
Raw Message
One of the terms bandied about w/r/t B1 security was "covert channels" --
an unauthorized user is not supposed to be able to know anything about
another user.
"Communication" in this case would include, but would not be limited to,
in-memory data.

"Another user" would usually not be the same as "a subsequent step in the
same job" but conceivably could be thought of as such.

You can decide for yourself to what extent (if any) z/OS Unix could be
thought to allow such channels. Maybe Unix (not just on z) brought about
the demise of B1 security, I have no idea; I have not heard B1 security
mentioned in a long time (that doesn't mean its concepts were bad).

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lou Losee
2017-12-04 13:04:26 UTC
Reply
Permalink
Raw Message
You may not have heard of B1 security, but I would suppose you have heard
of Common Criteria which also performs covert channel analysis.

Lou

--
Artificial Intelligence is no match for Natural Stupidity
- Unknown
Post by Peter Relson
One of the terms bandied about w/r/t B1 security was "covert channels" --
an unauthorized user is not supposed to be able to know anything about
another user.
"Communication" in this case would include, but would not be limited to,
in-memory data.
"Another user" would usually not be the same as "a subsequent step in the
same job" but conceivably could be thought of as such.
You can decide for yourself to what extent (if any) z/OS Unix could be
thought to allow such channels. Maybe Unix (not just on z) brought about
the demise of B1 security, I have no idea; I have not heard B1 security
mentioned in a long time (that doesn't mean its concepts were bad).
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2017-12-04 13:33:57 UTC
Reply
Permalink
Raw Message
The product I'm working on now has a deep stack. We have an assembler
back-end server with C++ wrapping it and a Java web server in the mix
wrapping the C++ layer. We decided we would use UNIX domain sockets for
the communication between the clients and server. This works well for
both ISPF and the web UI. The compelling reason was it doesn't need to
run authorized.  Our most experienced assembler programmers (and our
owners) were dubious about that at first but were won over when they
realized that the socket could be protected using UNIX file permissions
backed by RACF.
Post by Peter Relson
One of the terms bandied about w/r/t B1 security was "covert channels" --
an unauthorized user is not supposed to be able to know anything about
another user.
"Communication" in this case would include, but would not be limited to,
in-memory data.
"Another user" would usually not be the same as "a subsequent step in the
same job" but conceivably could be thought of as such.
You can decide for yourself to what extent (if any) z/OS Unix could be
thought to allow such channels. Maybe Unix (not just on z) brought about
the demise of B1 security, I have no idea; I have not heard B1 security
mentioned in a long time (that doesn't mean its concepts were bad).
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian Westerman
2017-12-05 03:28:10 UTC
Reply
Permalink
Raw Message
It's not the individual 2k which is the problem, it's the fact that (since we are dealing with automation of tasks, messages, and other "stuff") that we could have hundreds or thousands of them existing at any one point in time, and if they were all persistent, (meaning they were the life of the IPL), and there were a looonnnnggg time between IPL's, we could be talking some serious memory drain issues.

While this would not actually be "our" fault, providing the easy mechanism for someone to shoot themselves tends to make one look bad.

Brian

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bruce Hewson
2017-12-05 05:58:27 UTC
Reply
Permalink
Raw Message
Hello John,

Have you looked at using UNIX Sempahores?

They are persistent, needing to be explicitly created and explicitly deleted.

(we have a product which randomly forgets to delete them).
Post by 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
Regards
Bruce Hewson

ps: catching up on reading old digests.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-12-05 06:14:34 UTC
Reply
Permalink
Raw Message
Post by Bruce Hewson
Hello John,
Have you looked at using UNIX Sempahores?
​Never even occurred to me. I was considering UNIX message queues. For some
reason, they don't seem to be real popular. At least, I can't find many
examples of their use on the Web.​ But they require "cleaning up" too.
Post by Bruce Hewson
They are persistent, needing to be explicitly created and explicitly deleted.
(we have a product which randomly forgets to delete them).
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...