In a recent note, Walt Farrell said:
> Date: Mon, 7 Jul 2003 06:19:25 -0400
>
> It's probably easiest if you don't try to return anything to REXX at
> all, except a return code. Save the subtask information entirely
> external to REXX, e.g. in some storage anchored via name/token so
> subsequent invocations of your interface module can find it.
>
But how can I pass token back to the interface module when I
do the DETACH if the interface module doesn't return it to Rexx
when I do the ATTACH? I.e. how does the interface module know
which of my subtasks I wish to DETACH?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Mon, 7 Jul 2003 11:08:26 -0400
>
> Consider passing a token _in_ to the interface module to name each
> subtask. The interface module can maintain a list of tokens, TCB
> addresses, etc. and then later you can pass it the same token when you
> want to detach one of them.
>
Of course. Thanks. And another contributor has passed to me
off-list a pointer to the doc. The minor problems I see yet:
o Rexx has no intrinsic unique name generator. I suppose I can
use a date/time value, compressed to 16 characters.
o Surprisingly, name/token services appears to have no facility
to electively delete a name/token pair -- they simply remain
until the creating task terminates, then go away. I don't
see this as ever being a problem for my purposes, but it would
seem that for a long-running task it would be a resource leak.
Of course, one could create an anchor with name/token services
then manage a linked list oneself. I suspect this was pretty
much the design objective of name/token services.
Thanks again,
gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Tue, 15 Jul 2003 13:43:55 -0400
>
> The TSO convention is that unquoted names should be interpreted as
> <prefix>.rest_of_name
>
> ISPF developed the convention that if prefix and userID are not the
> same, ISPF would treat an unquoted name as <prefix>.<userID>.rest_of_name
>
Why?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Fri, 1 Aug 2003 07:47:55 -0400
>
> If you're not writing, you should not open for output. You will cause
> problems for someone, someday, or perhaps for yourself when the auditors
> come around to ask what you were doing.
>
Conversely, if you're not reading you should not open for input.
I have encountered a problem with an IBM product that does just that.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Fri, 27 Feb 2004 16:31:15 -0500
>
> Unfortunately, a leading "." and an otherwise blank line seems to either
> terminate a newsgroup message, or do something odd to the process that
> sends messages from the ibm-main mailing list to the news server.
>
> I've seen things like this before, but never took the time to track it down.
>
It's RFC 977 Network News Transfer Protocol:
2.4.1. Text Responses
Text is sent only after a numeric status response line has been sent
that indicates that text will follow. Text is sent as a series of
successive lines of textual matter, each terminated with CR-LF pair.
A single line containing only a period (.) is sent to indicate the
end of the text (i.e., the server will send a CR-LF pair at the end
of the last line of text, a period, and another CR-LF pair).
> It would be nice if Darren could find a way around this (perhaps munging
> such lines as he transmits them to the news server?).
>
(ibid):
If the text contained a period as the first character of the text
line in the original, that first period is doubled. Therefore, the
client must examine the first character of each line received, and
for those beginning with a period, determine either that this is the
end of the text or whether to collapse the doubled period to a single
one.
> --
> Walt Farrell, z/OS Security Server Design, IBM
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Wed, 31 Mar 2004 18:34:46 -0500
> >
> > o DYNALLOC is unsuitable for building multi-file tapes.
> >
> > o APF entanglement prevents invoking IEBCOPY from a Rexx EXEC.
>
> You should have no problem invoking IEBCOPY from a Rexx exec as long as
> you run the exec under IKJEFT01 or one its siblings.
>
Of course, I want to run IEBCOPY as a build processor under
"make". I could spawn "make" under IKJEFT01, then the Rexx
under make, then IEBCOPY under Rexx. But, I fear that's too
many "under"s, isn't it?
> (I wonder: as another alternative could you fork something and use
> execmvs to run IEBCOPY?)
>
(Aka BPX1EXM?) The basic flaw in BPX1EXM is it has no facility
for allocating data sets other than TASKLIB. (What were they
thinking!?)
> That doesn't help with DYNALLOC, though.
Thanks for your efforts.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Tue, 4 May 2004 08:53:00 -0400
>
> > As an example, I have this little program written in C; there's no way
> > I can terminate input unless I enter all 1024 characters...
>
> If you're referring to the shell provided by the OMVS command under TSO,
> you'll notice at the bottom of the screen your ESC (escape) setting.
> The character specified there acts as a "control" character. Thus, if
> you have ESC=^ (for example) then typing ^C would be a control-C, ^Z
> would be a control-Z, etc.
>
Expanding slightly:
o Conventionally, EOF is represented by control-D.
o If the ESC character is unavailable on your keyboard, but you're
using a terminal emulator with cut-and-paste capability, you may
be able to paste the displayed ESC character to your command line.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Thu, 27 Jan 2005 10:39:59 -0500
>
> POSIX says nothing about what auditors may do. The AUDITOR on our
> system can read or search directories, but not read files.
>
I don't accept this form of argument from omission as valid.
By analogy:
POSIX says nothing about what Eskimos may (or may not) do.
Therefore, granting special privileges to Eskimos is not
a POSIX violation.
Nonsense!
What POSIX does say is:
Linkname: File Access Permissions
URL: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_04
4.4 File Access Permissions
The standard file access control mechanism uses the file
permission bits, as described below.
Implementations may provide additional or alternate file access
control mechanisms, or both. An additional access control
mechanism shall only further restrict the access permissions
defined by the file permission bits. An alternate file access
control mechanism shall:
* Specify file permission bits for the file owner class, file
group class, and file other class of that file,
corresponding to the access permissions.
* Be enabled only by explicit user action, on a per-file
basis by the file owner or a user with the appropriate
privilege.
* Be disabled for a file after the file permission bits are
changed for that file with chmod(). The disabling of the
alternate mechanism need not disable any additional
mechanisms supported by an implementation.
> It is a specific privilege given to a user who needs the ability to do
> that in order to conduct audits, and in my opinion does not represent a
> security exposure or violation.
>
On reflection, I find the rationale for AUDITOR authority reasonable.
But it's clearly a POSIX deviation. Is it mentioned as a deviation
in the POSIX Conformance document?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Tue, 22 Feb 2005 07:00:03 -0500
>
> The "agent" would not need to do any authority checking. It would be
> forked by the original user, and thus run as that user, and JES would do
> all the appropriate authority checking based on that original user's ID.
>
Understood.
> As another list member pointed out, SDSF uses an SVC.
>
That other list member stated, IIRC, that SVC places the caller
in KEY 1, Supervisor state. If the Job Entry Subsystem is going
to verify authority, why is Supervisor state necessary, and why
is it necessary (as Roland observed) that the caller be loaded
from an Authorized linklib?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Tue, 22 Feb 2005 13:33:55 -0500
>
> On 2/19/2005 10:24 AM, [log in to unmask] wrote:
> > Don't think "GUI". Think "alternative to JCL". Nowadays,
> > my preference is to do as much as I can in Rexx (sometimes
> > POSIX shell script). But sometimes Rexx fails, and I must
> > revert to JCL, often generated/submitted by a Rexx EXEC.
> >
> > Those deficiencies in Rexx all arise from the absence of
> > APIs for facilities available in JCL. The requirements
> > should be for APIs to:
> > ...snipped...
> > o IEBCOPY
>
> REXX should work just fine with IEBCOPY. Assuming, of course, that
> you're not trying to use IEBCOPY from REXX from within the UNIX shell :-)
>
Ah, you understand the problem; you seem unsympathetic.
OK. If UNIX shell is out, then how about IRXJCL? And Rexx
invoked via the documented API from a problem program?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Fri, 25 Feb 2005 09:12:27 -0500
> >
> > What about the tso shell command?
> > You can use it to run a TSO/E command, e.g. SUBMIT, from the shell.
> > See
> > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZA550/CCONTENTS?S
> HELF=BPXZSH50&DN=SA22-7802-06&DT=20040610143257
>
> That should work, assuming, of course, that you're running under TSO
> using the OMVS shell. If you telnet or rlogin to a shell, or run
> BPXBATCH, you don't have access to TSO facilities.
>
True:
SPPG@no-spam tso submit foo.bar
submit foo.bar
RC(12)
IKJ79204I You attempted to run an unsupported function in a dynamic TSO Environment.
But, lately there's an alternative:
SPPG@no-spam rexx "address 'TSO' 'submit foo.bar'"
IKJ56269I DATA SET FOO.BAR NOT FOUND
.. I'm assuming that it would have worked if I had given it a valid
data set name.
That said, it would still be extremely valuable if "SUBMIT" supported an
"INDDNAME" option. This would allow SUBMITting HFS files after a suitable
ALLOCATE, and by ALLOCATEing to a pipe, SUBMITting from ISPF without
using a temporary file, thus eliminating the FAQ concerning Sx37 from SUBMIT.
(One might just SUBMIT via SYSOUT INTRDR, but some users demand the
collateral effects of SUBMIT.)
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Fri, 25 Feb 2005 12:29:29 -0500
>
> > SPPG@no-spam rexx "address 'TSO' 'submit foo.bar'"
> > IKJ56269I DATA SET FOO.BAR NOT FOUND
>
> That one I'm surprised at. I didn't realize the z/OS UNIX REXX
> implementation supported address TSO when you're outside of the OMVS
> shell. Something new learned.
>
WJS does good work.
> Did you notice Big Iron's mention of the submit() function in z/OS UNIX
> REXX? Or are you familiar with it from other sources? See
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB650/5.20?SHELF=EZ
> 2ZO10D&DT=20040615133321
> for details. It takes input from a stem variable, submits to JES, and
> returns the job number.
>
Other customers may be less comfortable with Rexx than I, and it
requires at least the coding to populate the stem.
Is this suitable for enormous jobs? Remember the history of Sx37
problems with TSO SUBMIT.
Hmmm. On z/OS 1.5:
SPPG@no-spam rexx "trace R; X.1='//X JOB Y'; X.0=1; say submit('X.')"
1 *-* X.1='//X JOB Y'
>>> "//X JOB Y"
*-* X.0=1
>>> "1"
*-* say submit('X.')
IRX0250E System abend code 66D, reason code 00000049.
IRX0253E Abend in external function SUBMIT.
14.44.47 STC07143 IEA995I SYMPTOM DUMP OUTPUT 697
697 SYSTEM COMPLETION CODE=66D REASON CODE=00000031
697 TIME=14.44.47 SEQ=03870 CPU=0040 ASID=0077
697 PSW AT TIME OF ERROR 071C1000 85C0514E ILC 2 INTC 0D
697 NO ACTIVE MODULE FOUND
697 NAME=UNKNOWN
697 DATA AT PSW 05C05148 - 41F00031 0A0D47F0 C12E5830
697 AR/GR 0: 00000000/80000005 1: 00000000/0466D000
697 2: 01FF000B/7FFF9F08 3: 00000000/006FDE88
697 4: 00000000/006E09E0 5: 00000000/006FCD08
697 6: 00000000/00000005 7: 00000000/00F99680
697 8: 00000000/43E2AE38 9: 00000000/80000005
697 A: 00000000/05C0776E B: 00000000/7FA505F8
697 C: 00000000/85C05034 D: 00000000/7FA505F8
697 E: 00000000/0000000B F: 00000000/00000031
697 END OF SYMPTOM DUMP
1 +++ say submit('X.')
1 +++ /* REXX Useful! */ interpret arg(1)
IRX0040I Error running /mvsoeecc/sppg/bin/rexx, line 1: Incorrect call to routine
Whatever I did wrong, it's not telling me very nicely. Too many
functions (I have one PMR open on another) believe the IRX0040I
is a suitable report of an error. Hmmm:
# 2.451 "z/OS V1R5.0 MVS System Codes"
31
A TSO/E service that requires a TSO/E environment was invoked in
a non-TSO/E environment.
Ironic in that the command is documented in:
5.20 "z/OS V1R5.0 Using REXX and z/OS UNIX System Services"
___________________________________________________________________
5.20 submit()
.. and I tried it from a UNIX shell. Wouldn't
BPXWDYN( 'alloc INTRDR' ); EXECIO
be better?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Fri, 20 May 2005 12:10:51 -0400
>
> On 5/19/2005 12:41 PM, [log in to unmask] wrote:
> > A customer (through an auditor) has posed a question to us: Job 'A' runs
> > and ends. Job 'B' then comes in and obtains some of the system storage
> > that Job 'A' had. The question is, can Job 'B' see data in that memory
> > originally owned by Job 'A'?
> >
> > Theoretically, yes, right? Is there a way to prevent this? (which I'm
> > sure will be the followup question) I know this sounds a little silly but
> > it seems to be a concern to someone.
>
> For the answer to the auditor, I think you should focus on what happens
> with normal application programs. For them, the answer is a definite
> "no". And data that an unauthorized program places into memory that it
> allocated in job A will not survive into job B. The initiator or other
> system functions will free all of that application-related storage at
> the end of each job step.
>
A paranoid might easily suspect that the (apparently naive) auditor
was engaged with the task of spreading FUD about mainframes and
proving that it's safer to have only one person using each computer.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Sun, 5 Jun 2005 07:45:19 -0400
> >
> > Now, suppose support were added to run 3270 OMVS directly from a tn3270
> > connection, with no TSO involvement. Then a given user could run
> > several 3270 OMVS sessions, since the TSO one-session-per-user limit
> > would not apply.
>
> time and money doing it. There are always some questions to answer,
> such as "which TSO session should a SEND command choose", but those
>
Such questions, including the related, "which session should an
operator's CANCEL command choose," are predicated on the confusion
of session ID with user ID. If the argument to such commands is,
properly, a session ID (TSUnnnn) as opposed to a user ID, the effect
of the command should be directed to that session. The possibility
remains that a user ID could be supplied as the argument, in which
case the message should be sent to all sessions owned by that user,
or all sessions owned by that user should be cancelled.
This is all similar to the same conceptual error that gave rise
to Barry Merrill's tale (likely apocryphal) of the confusion
that arose when Alan Scheer caused responses that should have
been directed to a session ID to be misdirected instead to a
user ID.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Wed, 19 Oct 2005 08:57:06 -0400
>
> > Does the TSO security model, such as it is, preclude wider use
> > of modal commands or the development of modal commands by users?
>
> I see no relationship between modality and security, so I would have to
> say no, it doesn't.
>
> If you see some relationship that I don't, please explain further.
> Perhaps you're considering something to be "security" that I don't.
>
I was trying to imagine how support for modal applications could
be implemented in a modular and extensible fashion, so that a
programmer might even be able to code his own modal applications
with no specific modifications to the TMP.
Suppose the modal application were ATTACHEd (or spawn()ed) and
control were returned to the TMP without doint a WAIT (or waitpid),
but leaving a communication channel open between the application
and the TMP; perhaps ECB semaphores, POSIX pipes, or sockets.
(I suspect the implementation of the modal EDIT is somewhat like
this.) Further line input from the TMP, CLIST, or EXEC would
be passed to the modal application, which would return messages
and status. This interaction would continue until the TMP passed
the application an END command and the application returned a
status indicating it exited.
But I understand, however poorly, that part of TSO security depends
on preventing concurrency, so a task/process left in background
can't meddle with storage of a possibly authorized command. Permitting
the concurrency I envision above might compromise this protocol.
As an experiment, I wrote an EXEC which does a SYSCALL spawn and
exits without waitpid() for the child. With _BPX_SHAREAS = NO, it
returns normally and leaves the child running in the background
until it terminates. With _BPX_SHAREAS = YES, it ABENDs with
SA03. So I can leave a concurrent process in a different address
space, but not in the same address space where it might meddle
with working storage of subsequent commands. I suspect this
is routine operation of Classic MVS; not code added specifically
to protect the TMP from spawn().
I don't know EDIT or IPCS enough to try an experiment to see whether
the flavor of "address TSO" peculiar to Rexx programs started from
z/OS Unix shell plays well with those commands. (Too bad WJS
doesn't follow this list; he'd likely know.)
Is execution of the modal EDIT from ISPF 6 fully supported?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Tue, 28 Feb 2006 12:08:09 -0500
>
> On 2/28/2006 10:47 AM, [log in to unmask] wrote:
> > The good intention was to dispel the expectation, or wishful thinking,
> > that the EFC could invert all transformations performed by ICSF.
> >
> > Clearly it fell short of the mark insofar as it easily misled you
> > and me. A clarification might be helpful, such as a paraphrase
> > of John E.'s words to:
> >
> > Data which ICSF has compressed and encrypted can be decrypted
> > but not uncompressed by the Encryption Facility Client.
>
> That's not quite right either, gil.
>
I thought it was.
> Remember that there are two pieces involved. The IBM Encryption
> Facility for z/OS, and the separate Encryption Facility Client.
>
Is "The IBM Encryption Facility for z/OS" different from ICSF?
If so, I'm quite wrong.
> The usual modes of operation are expected to be:
> (1)(a) optionally compress, and encrypt using the Encryption Facility
> for z/OS on one system;
> (b) decrypt, and (if compressed) uncompress using the Encryption
> Facility for z/OS on another z/OS system, or the same z/OS system.
>
> or
> (2) (a) encrypt using the Encryption Facility for z/OS. Then
> (b) decrypt on some non-z/OS system using the Encryption Facility
> Client.
>
> or
> (3) (a) encrypt on some non-z/OS system using the Encryption Facility
> Client. Then
> (b) decrypt on z/OS using the Encryption Facility for z/OS.
>
> The compression in (1)(a) is the IBM System z hardware compression,
> which is not supported anywhere else but in the IBM hardware.
>
(Until someone reverse-engineers it. And some customers might
feel uneasy having critical data compressed and/or encrypted
by a technique not openly described and subject to peer review.)
> Note that wherever I've said the Encryption Facility Client was running
> on non-z/OS, it could also run on z/OS. However, in any case, it can
> only do encryption/decryption, it cannot make use of the hardware
> compression functions.
>
> The real point to understand is that there are two functions being
> described: the Encryption Facility and the Encryption Facility Client.
>
Except for my use of "ICSF" where you use "the Encryption Facility"
I was attempting to say what you clearly said. Was I overly terse
and/or confused in my terminology?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Fri, 10 Mar 2006 10:53:09 -0500
>
> He is trying to establish a different security environment within his
> server, in which all requests made by the system need to be processed as
> a different user. He is not making a request on behalf of another user.
>
> In that situation, he needs to do the same kinds of things that the
> system would do, including manipulating the TCB.
>
Would an alternative be to use Unix Services' setuid()? It
seems to me that Unix Services provide an additional security
benefit in that fork() allows the child process to run in a
separate address space, a desirable form of isolation.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Mon, 24 Apr 2006 08:41:59 -0400
>
> On 4/24/2006 7:28 AM, Steve Flynn wrote:
> > ...snipped...
> > PUT DD:REPFILE 'SOME.REMOTE.GDG.BASE(+1)'
>
Is FTP GDG-savvy? There's a long litany of problems accessing
GDG generations by any method other than JCL DD allocation.
I see:
4.8 "z/OS V1R7.0 Comm Svr: IP User's Guide and Commands"
4.8 Generation data group support
... You cannot use FTP to create a new GDG, ...
And, in the next paragraph:
... Therefore, when creating a new GDG [ ... ], at least one of the
following must be true: ...
??? So, they tell me I can't do it, then proceed to tell me the
rules for doing it? Needs editorial revision.
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b950/4.2.4?SHELF=EZ2ZO10G&DT=20050708142126
>
Wherein I note:
4.2.4 "z/OS V1R7.0 Comm Svr: IP User's Guide and Commands"
4.2.4 DD name support
The FTP Client API does not support DD name transfers. The DD names
associated with a batch job that invokes an application program using
the FTP Client API are not available to the spawned FTP client process.
That's pretty harsh. What was the design rationale for spawning
the client process rather than using a more DD name friendly
mechanism such as ATTACH? Is there any security concern that
would preclude running an FTP server task in the same address
space as the caller?
But, I wondered, could one use DYNALLOC (BPXWDYN) to capture the
volume and provide that to FTP?
So, in the same publication:
5.34 "z/OS V1R7.0 Comm Svr: IP User's Guide and Commands"
5.34 LOCSIte subcommand--Specify site information to the local host
VOLume
Specifies the volume serial number for allocation of new data sets.
Alas, the operant word is "new". What was the design rationale
for not applying LOCSITE VOLUME likewise to existing data sets?
I note that the API restriction does not apply to invoking
FTP in a batch job step.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Wed, 14 Jun 2006 13:58:51 -0400
>
> you can set the UMASK via SITE UMASK nnn (note that with some FTP
> clients you may need to use QUOTE SITE UMASK nnn).
>
Thanks for the implied correction. Apparently Mark and I both
overlooked that the OP was discussing PC client and z/OS server,
rather than vice-versa.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Tue, 1 Aug 2006 15:49:35 -0400
>
> On 8/1/2006 10:10 AM, Edward Jaffe wrote:
> >
> > No. Holding a shared ENQ prevents others from acquiring an exclusive ENQ
> > on the same resource and modifying it. To maintain the integrity of the
> > resource, you use RET=CHNG to upgrade from shared to exclusive without
> > losing control. If you were required to DEQ and then re-ENQ to perform
> > the upgrade, you would lose control of the resource between the time you
> > inspected it and the time you had the necessary serialization to update
> > it. In the worst case scenario, someone else could change (or even
> > delete) the resource in-between!!
>
> Of course, if anyone else also has the resource with a shared ENQ, your
> RET=CHNG will fail, and at that point you have no choice but to DEQ and
> try again from the beginning (presumably starting with EXC that time
> around).
>
What do you gain by performing the DEQ? The EXCL ENQ will immediately
fail and continue to fail until all other jobs DEQ the resource.
Isn't it as good or better simply to re-issue the RET=CHNG until
it works, or use the WAIT option if you have the authority.
But, yes, I was using rhetoric to make the same point Binyamin made
more explicitly: doing a DEQ; ENQ is subject to the same hazard
of interruption by other jobs whether one uses the sequence to
downgrade or upgrade an ENQ. If it's unacceptable for upgrading,
it's likewise unacceptable for downgrading.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Tue, 22 Aug 2006 11:54:42 -0400
>
> On 8/21/2006 7:55 PM, gilmap@no-spam wrote:
> > Is there any way to search the archives of these lists
> > so that the first page of hits presented contains the
> > fifty most recent hits, rather than the fifty oldest?
>
> Perhaps you could restrict the date range you're searching?
>
No, I can't properly pose that question without knowing its
answer a priori: I can't choose a date range without knowing
whether the fifty most recent hits were last week or three
years ago.
An option to present the hits in reverse chronological order
would be very useful.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Tue, 19 Sep 2006 14:00:51 -0400
>
> ... Generally it is more a question, I think,
> of whether the program is doing something that you would want run under
> TSO, given the dispatching priority of TSO users, and some environmental
> characteristics (how long the user will be waiting while it runs, for
> example) that determines whether you allow the programs to run under
> TSO/E or not.
>
Alas, this misses the mark considerably in that it fails to
distinguish between interactive TSO sessions and use of the TMP
in batch. AUTHPGM NAMES is the same for both, isn't it?
Perhaps for this purpose AUTHPGM should govern only calling
programs from interactive sessions, and batch TMP should be
free to invoke any authorized program, listed or not.
There are similar concerns with dynamic allocation of tape drives.
The administrators' reasonable desire not to allow drives to be
monopolized during programmers' think time should not be addressed
by the crude expedient of prohibiting (or allowing) all dynamic
allocation and mounting of tapes.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, Walt Farrell said:
> Date: Mon, 5 Mar 2007 12:13:02 -0500
>
> On 3/5/2007 12:04 PM, gilmap@no-spam wrote:
> >>
> > ... But in SDSF "SJ" while
> > EDITSET shows "Confirm Cancel" as disabled, SDSF still asks me
> > to confirm Cancel.
> >
> > ISPF really needs to get its act together.
>
> I would say that ISPF does have its act together, gil. It allows
>
Not in my perception. You're showing an unseemly excess of
employee loyalty.
> applications to run with different application prefixes, settings,
> variable pools, and commands. You've described one of the effects of
> that flexibility.
>
> SDSF runs with a different application profile (ISF) than PDF does
> (ISR). Thus the commands available are different, the settings are
> maintained separately, etc.
>
> You need to do the EDITSET (or any other action that sets profile
> variables) once for each different ISPF application you're using.
>
Do you, then, consider it correct, or a manifestation of "flexibility"
that EDITSET under SDSF displays "Confirm Cancel" as disabled, yet
the Cancel command itself still requests confirmation?
And "flexibility" can be a PITA when there's no global default
setting and the customer is required to do the profile setting
for each application, and suffers a high astonishment factor when
entering a seldom-used applicaton and encountering a deviation
from behavior that had generally been observed to be uniform and
stable.
Is there a way to make such settings globally rather than locally?
It would be great to have a checkbox that says "Apply these settings
to all applications."
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html