Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Mike Hochee]

Hi Peter, 

I came across a similar use case a couple times over the past year or so. 
Shifting priorities have prevented me from doing much with it, but while at the 
most recent SHARE in Fort Worth, I asked one of the DFSMS architects about it. 
She encouraged me to check out the CSI, specifically, fields UDATASIZ and 
COMUDSIZ. They appeared to satisfy my use case, although as others have 
mentioned there are a few restrictions especially for UDATASIZ. 

HTH, 
Mike  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Thursday, May 14, 2020 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

Caution! This message was sent from outside your organization.

This question came to me from a co-worker: Is there any API to get the byte 
file size of a non-VSAM, non-zFS, non-database file in z/OS?  I.E., byte file 
size for plain sequential files?

I am aware of the "old way" of reading the VTOC of a volume to get the various 
DSCB's that total up disk extents, but that gets complicated quickly for 
multi-volume files, and was never guaranteed to be accurate as to the actual 
byte count of data in the file except in the RECFM=FS/FBS case anyway.

There is always the performance-killing option of just reading the whole file 
and totaling up the length of every record (or block depending on how you 
structure the reads), but no one would call that an API.

As far as I know there is no such API in z/OS, and this is what I told my 
co-worker, but am I wrong?  Is there an alternative of which I am not aware?

TIA for your input.

Peter
--



This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

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

Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Charles Mills]

> finer control of error reporting  ... And I use RTDDN() lest the Exec be 
> embedded

I hear you. This is a one-off internal-use-only. Something of a proof of 
concept. If this ever became a "product" I would probably re-write in C++ and 
worry about that sort of thing.

> So, you need SPIN to process before end of step.

I would think so but @Rob Jackson seems to indicate not. Easy to add if so.

> And for JES3, you're SOL.  The only supported option is NO.

Again, this is a one-off internal-use-only. JES2.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, May 15, 2020 2:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

On Fri, 15 May 2020 13:50:08 -0700, Charles Mills wrote:

>Thanks. Yeah, I love BPXWDYN but ALLOC/FREE would be easier here. 
>
How?  I prefer BPXWDYN because of the finer control of error reporting.
And I use RTDDN() lest the Exec be embedded in a larger process with
the risk of DDNAME collision, perhaps because of concurrency.

>I see that
>ALLOC supports SPIN(UNALLOC) but you are saying I don't need it?
>
>From the JCL Ref.:
UNALLOC
JES2 only. Indicates that the system makes the data set available for
processing immediately when the data set is unallocated. If you
dynamically unallocate the sysout data set, either explicitly or by 
specifying
FREE=CLOSE, the system makes the data set available for processing
immediately. If you do not dynamically unallocate it, the sysout data set
is unallocated at the end of the step, and the system makes it available
for processing then.

So, you need SPIN to process before end of step.

And for JES3, you're SOL.  The only supported option is NO.
(Unless you spawn your script with _BPX_SHAREAS=NO?  Ugh!)

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

Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Paul Gilmartin]

On Fri, 15 May 2020 13:50:08 -0700, Charles Mills wrote:

>Thanks. Yeah, I love BPXWDYN but ALLOC/FREE would be easier here. 
>
How?  I prefer BPXWDYN because of the finer control of error reporting.
And I use RTDDN() lest the Exec be embedded in a larger process with
the risk of DDNAME collision, perhaps because of concurrency.

>I see that
>ALLOC supports SPIN(UNALLOC) but you are saying I don't need it?
>
From the JCL Ref.:
UNALLOC
JES2 only. Indicates that the system makes the data set available for
processing immediately when the data set is unallocated. If you
dynamically unallocate the sysout data set, either explicitly or by 
specifying
FREE=CLOSE, the system makes the data set available for processing
immediately. If you do not dynamically unallocate it, the sysout data set
is unallocated at the end of the step, and the system makes it available
for processing then.

So, you need SPIN to process before end of step.

And for JES3, you're SOL.  The only supported option is NO.
(Unless you spawn your script with _BPX_SHAREAS=NO?  Ugh!)

-- gil

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

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Jeremy Nicoll]

On Fri, 15 May 2020, at 21:58, Charles Mills wrote:
> The OP had rejected "just reading the whole file." Someone said "just use
> EXECIO and look in STEM.0" and I was just pointing out that that was reading
> the whole file.

I have read the whole thread.

There was a discussion about memory constraints, and you said:

   "But everything to do with how big a stem variable array it can build."

The point of the code I posted is that the stem only ever holds (say) 500 
records
in total, which removes that problem.  

Clearly you could do I/O one record at a time but it would be very slow for a 
huge file.  Reading 500 or 5000 or 50,000 records in each iteration around the 
loop is considerably faster AND doesn't need as much memory as the whole
file would.


-- 
Jeremy Nicoll - my opinions are my own.

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

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Jeremy Nicoll]

On Fri, 15 May 2020, at 19:25, Tom Brennan wrote:
> That's a Rexx I never tried, probably out of fear of the "OO" 
> designation :)

You can write code in 'Classic' REXX, in ooREXX and incorporate 
no, or just a little or a lot of OO stuff.

Most of my code is more or less Classic, but (on Windows) I quite
often read an existing file by eg:

   mystream = .stream~new("C:\this\that\other.file")

(which is vaguely analogous to allocating a dd in TSO), then

   linez = mystream~arrayin

which forms an ooREXX array object (named linez) from the lines of 
data, then

   mystream~close

which closes the file.  Then eg 

  say "The file has" linez~items "lines"

   do aline over linez
   say "a line:" aline
   end

will list all of the lines.  ooREXX does now have an "execio" subcommand
but before that came about this small excursion into objects is how I have
quickly and easily read a text file without having to loop to do the I/O
explicitly one record at a time.  The array object isn't a stem, but one can
of course access each element within it explicitly, as well as using the "do
... over" iterative thing. 

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Charles Mills]

The OP had rejected "just reading the whole file." Someone said "just use
EXECIO and look in STEM.0" and I was just pointing out that that was reading
the whole file.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jeremy Nicoll
Sent: Friday, May 15, 2020 1:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM,
non-zFS, non-database files?

On Fri, 15 May 2020, at 19:48, Charles Mills wrote:
> But everything to do with how big a stem variable array it can build.

But there's no need, if counting the records in a file (or even summing
their 
lengths as well) to store them all.Use something like:

/* REXX
   Call as: %linkount dsn num

 where: dsn is fully qualified, with/without quotes
num is number of lines read at a time, default is 500
*/
parse arg dsname chunksize ;  dsname = strip(dsname,"B","'")
if ^datatype(chunksize,"W") then chunksize = 500

address tso "allocate fi(huge) da('"dsname"') shr reuse"

linecount = 0
do forever
   "execio" chunksize "diskr huge (stem somelines.";  erc = rc
   linecount = linecount + somelines.0
   if erc > 0 then leave
end
"execio 0 diskr huge (finis";  "free fi(huge)"   /* close+free */

say dsname "has" linecount "lines."



One could possibly preface that code with one of the LISTDSI-based
solutions to get an approximate idea of the allocated size of the file
& hence determine an appropriate chunksize, depending on whether
you want the count to be faster/slower or to waste more/less memory
while running.

-- 
Jeremy Nicoll - my opinions are my own.

--
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: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Allan Staller]

//XX DD SYSOUT=(B,,SMTP),FREE=CLOSE should do what you specified in the OP.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, May 15, 2020 3:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I am using GETMSG so must run under TSO/IRXEXEC already. Should have mentioned 
that.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Friday, May 15, 2020 1:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

The only difference I can see between ALLOC and bpxwdyn is that the former 
requires a TSO environment.  That's usually not much of a burden, but if you 
want to run under IRXJCL, you'd have to go with bpxwdyn.  I also like that it 
supports system-generated ddname that it will return, although that doesn't 
seem needed here.

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Charles Mills]

I am using GETMSG so must run under TSO/IRXEXEC already. Should have mentioned 
that.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Friday, May 15, 2020 1:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

The only difference I can see between ALLOC and bpxwdyn is that the former
requires a TSO environment.  That's usually not much of a burden, but if
you want to run under IRXJCL, you'd have to go with bpxwdyn.  I also like
that it supports system-generated ddname that it will return, although that
doesn't seem needed here.

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

Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Charles Mills]

Interesting. I will keep that in mind. *Think* I will go with ALLOC/FREE, but 
will keep this in mind.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Bickerdike
Sent: Friday, May 15, 2020 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

Submit a job to send the email. The email body won't overwhelm SYSIN. The
REXX program Just needs to put a wrapper around the email and submit.

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

Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Charles Mills]

That is one cool kludge! I had thought of having multiple DD's MAIL01, MAIL02, 
... but this would be even easier. A little too kludgey, and I have no idea how 
many times I might send an e-mail between restarts, but it is still a very cool 
notion. Thanks!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Friday, May 15, 2020 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

If you know how often the email is to be sent (1/2/3/4 times a day)
and the Bounce (IPL) schedule, you can repeat the DDNAME and each
message will use 1 DDNAME iteration.

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

Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Charles Mills]

Thanks. Yeah, I love BPXWDYN but ALLOC/FREE would be easier here. I see that
ALLOC supports SPIN(UNALLOC) but you are saying I don't need it?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jackson, Rob
Sent: Friday, May 15, 2020 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

Sounds right to me, but in REXX, I've always just done the following:

"ALLOC FI(MAIL) SYSOUT(B) WRITER(SMTP) LRECL(80) RECFM(F)"

Then open, write to it, close it, and free it; repeat.

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Charles Mills
Sent: Friday, May 15, 2020 4:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Looking for clarification/guidance on SMTP DD FREE/SPIN

[External Email. Exercise caution when clicking links or opening
attachments.]

I am designing a long-running Rexx program that will from time to time
generate an e-mail via the SMTP server. The idea is to allocate a DD
SYSOUT=(B,SMTP) and write the SMTP commands to it. I've never done that
before so I have some questions:

- Am I correct in my assumption that I will have to "spin" the dataset
before the SMTP server will pick it up?
- Assuming Yes to the first question, am I correct (a.) that
FREE=CLOSE,SPIN=UNALLOC on the DD will get the records over to SMTP on
EXECIO (FINIS; but that (b.) at that point the DD "no longer exists" -- that
I will get an error if I try to open it again? (Recall the program is
"long-running" and needs to generate multiple e-mails "from time to time."
They need to go out more or less as created, not in a big batch later on.)
- Not a huge deal if so, I guess. I can use BPXWDYN to allocate my DD again
and again rather than JCL. Anyone have any better ideas?

Thanks. Outside-the-above-box suggestions cheerfully considered. I'm pretty
much set on Rexx, e-mails, and "long-running with multiple e-mails from time
to time" but will consider other possibilities.

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally
privileged and/or confidential information. If you are not the intended
recipient(s), or the employee or agent responsible for delivery of this
message to the intended recipient(s), you are hereby notified that any
dissemination, distribution, or copying of this e-mail message is strictly
prohibited. If you have received this message in error, please immediately
notify the sender and delete this e-mail message from your computer.

--
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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Jeremy Nicoll]

On Fri, 15 May 2020, at 19:48, Charles Mills wrote:
> But everything to do with how big a stem variable array it can build.

But there's no need, if counting the records in a file (or even summing their 
lengths as well) to store them all.Use something like:

/* REXX
   Call as: %linkount dsn num

 where: dsn is fully qualified, with/without quotes
num is number of lines read at a time, default is 500
*/
parse arg dsname chunksize ;  dsname = strip(dsname,"B","'")
if ^datatype(chunksize,"W") then chunksize = 500

address tso "allocate fi(huge) da('"dsname"') shr reuse"

linecount = 0
do forever
   "execio" chunksize "diskr huge (stem somelines.";  erc = rc
   linecount = linecount + somelines.0
   if erc > 0 then leave
end
"execio 0 diskr huge (finis";  "free fi(huge)"   /* close+free */

say dsname "has" linecount "lines."



One could possibly preface that code with one of the LISTDSI-based
solutions to get an approximate idea of the allocated size of the file
& hence determine an appropriate chunksize, depending on whether
you want the count to be faster/slower or to waste more/less memory
while running.

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Steve Smith]

The only difference I can see between ALLOC and bpxwdyn is that the former
requires a TSO environment.  That's usually not much of a burden, but if
you want to run under IRXJCL, you'd have to go with bpxwdyn.  I also like
that it supports system-generated ddname that it will return, although that
doesn't seem needed here.

sas

On Fri, May 15, 2020 at 4:25 PM Roberto Halais 
wrote:

> Yes. That’s the way I’ve done and it works fine.
>
>
> On Fri, May 15, 2020 at 4:20 PM Jackson, Rob 
> wrote:
>
> > Sounds right to me, but in REXX, I've always just done the following:
> >
> > "ALLOC FI(MAIL) SYSOUT(B) WRITER(SMTP) LRECL(80) RECFM(F)"
> >
> > Then open, write to it, close it, and free it; repeat.
> >
> > First Horizon Bank
> > Mainframe Technical Support
> >
>

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

Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Roberto Halais]

Yes. That’s the way I’ve done and it works fine.


On Fri, May 15, 2020 at 4:20 PM Jackson, Rob 
wrote:

> Sounds right to me, but in REXX, I've always just done the following:
>
> "ALLOC FI(MAIL) SYSOUT(B) WRITER(SMTP) LRECL(80) RECFM(F)"
>
> Then open, write to it, close it, and free it; repeat.
>
> First Horizon Bank
> Mainframe Technical Support
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Charles Mills
> Sent: Friday, May 15, 2020 4:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Looking for clarification/guidance on SMTP DD FREE/SPIN
>
> [External Email. Exercise caution when clicking links or opening
> attachments.]
>
> I am designing a long-running Rexx program that will from time to time
> generate an e-mail via the SMTP server. The idea is to allocate a DD
> SYSOUT=(B,SMTP) and write the SMTP commands to it. I've never done that
> before so I have some questions:
>
> - Am I correct in my assumption that I will have to "spin" the dataset
> before the SMTP server will pick it up?
> - Assuming Yes to the first question, am I correct (a.) that
> FREE=CLOSE,SPIN=UNALLOC on the DD will get the records over to SMTP on
> EXECIO (FINIS; but that (b.) at that point the DD "no longer exists" --
> that I will get an error if I try to open it again? (Recall the program is
> "long-running" and needs to generate multiple e-mails "from time to time."
> They need to go out more or less as created, not in a big batch later on.)
> - Not a huge deal if so, I guess. I can use BPXWDYN to allocate my DD
> again and again rather than JCL. Anyone have any better ideas?
>
> Thanks. Outside-the-above-box suggestions cheerfully considered. I'm
> pretty much set on Rexx, e-mails, and "long-running with multiple e-mails
> from time to time" but will consider other possibilities.
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> Confidentiality notice:
> This e-mail message, including any attachments, may contain legally
> privileged and/or confidential information. If you are not the intended
> recipient(s), or the employee or agent responsible for delivery of this
> message to the intended recipient(s), you are hereby notified that any
> dissemination, distribution, or copying of this e-mail message is strictly
> prohibited. If you have received this message in error, please immediately
> notify the sender and delete this e-mail message from your computer.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Politics: Poli (many) - tics (blood sucking parasites)

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

Re: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Steve Smith]

I think you've got it right.  When a DD is unallocated, the DDNAME is
indeed gone, except... you can put duplicate DDNAMES in JCL for a step, and
when the first is freed, the next one steps in.  So you could avoid calling
bpxwdyn by pre-allocating a bunch of them.  More or less obviously, that's
not the right way to do it in your situation.  Use bpxwdyn.

sas


On Fri, May 15, 2020 at 4:08 PM Charles Mills  wrote:

> I am designing a long-running Rexx program that will from time to time
> generate an e-mail via the SMTP server. The idea is to allocate a DD
> SYSOUT=(B,SMTP) and write the SMTP commands to it. I've never done that
> before so I have some questions:
>
> - Am I correct in my assumption that I will have to "spin" the dataset
> before the SMTP server will pick it up?
> - Assuming Yes to the first question, am I correct (a.) that
> FREE=CLOSE,SPIN=UNALLOC on the DD will get the records over to SMTP on
> EXECIO (FINIS; but that (b.) at that point the DD "no longer exists" --
> that
> I will get an error if I try to open it again? (Recall the program is
> "long-running" and needs to generate multiple e-mails "from time to time."
> They need to go out more or less as created, not in a big batch later on.)
> - Not a huge deal if so, I guess. I can use BPXWDYN to allocate my DD again
> and again rather than JCL. Anyone have any better ideas?
>
> Thanks. Outside-the-above-box suggestions cheerfully considered. I'm pretty
> much set on Rexx, e-mails, and "long-running with multiple e-mails from
> time
> to time" but will consider other possibilities.
>
> Charles
>
> --
> 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: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Wayne Bickerdike]

Submit a job to send the email. The email body won't overwhelm SYSIN. The
REXX program Just needs to put a wrapper around the email and submit.

On Sat, May 16, 2020, 06:08 Charles Mills  wrote:

> I am designing a long-running Rexx program that will from time to time
> generate an e-mail via the SMTP server. The idea is to allocate a DD
> SYSOUT=(B,SMTP) and write the SMTP commands to it. I've never done that
> before so I have some questions:
>
> - Am I correct in my assumption that I will have to "spin" the dataset
> before the SMTP server will pick it up?
> - Assuming Yes to the first question, am I correct (a.) that
> FREE=CLOSE,SPIN=UNALLOC on the DD will get the records over to SMTP on
> EXECIO (FINIS; but that (b.) at that point the DD "no longer exists" --
> that
> I will get an error if I try to open it again? (Recall the program is
> "long-running" and needs to generate multiple e-mails "from time to time."
> They need to go out more or less as created, not in a big batch later on.)
> - Not a huge deal if so, I guess. I can use BPXWDYN to allocate my DD again
> and again rather than JCL. Anyone have any better ideas?
>
> Thanks. Outside-the-above-box suggestions cheerfully considered. I'm pretty
> much set on Rexx, e-mails, and "long-running with multiple e-mails from
> time
> to time" but will consider other possibilities.
>
> Charles
>
> --
> 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: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Mike Schwab]

If you know how often the email is to be sent (1/2/3/4 times a day)
and the Bounce (IPL) schedule, you can repeat the DDNAME and each
message will use 1 DDNAME iteration.

On Fri, May 15, 2020 at 8:08 PM Charles Mills  wrote:
>
> I am designing a long-running Rexx program that will from time to time
> generate an e-mail via the SMTP server. The idea is to allocate a DD
> SYSOUT=(B,SMTP) and write the SMTP commands to it. I've never done that
> before so I have some questions:
>
> - Am I correct in my assumption that I will have to "spin" the dataset
> before the SMTP server will pick it up?
> - Assuming Yes to the first question, am I correct (a.) that
> FREE=CLOSE,SPIN=UNALLOC on the DD will get the records over to SMTP on
> EXECIO (FINIS; but that (b.) at that point the DD "no longer exists" -- that
> I will get an error if I try to open it again? (Recall the program is
> "long-running" and needs to generate multiple e-mails "from time to time."
> They need to go out more or less as created, not in a big batch later on.)
> - Not a huge deal if so, I guess. I can use BPXWDYN to allocate my DD again
> and again rather than JCL. Anyone have any better ideas?
>
> Thanks. Outside-the-above-box suggestions cheerfully considered. I'm pretty
> much set on Rexx, e-mails, and "long-running with multiple e-mails from time
> to time" but will consider other possibilities.
>
> Charles
>
> --
> 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: Looking for clarification/guidance on SMTP DD FREE/SPIN

[Jackson, Rob]

Sounds right to me, but in REXX, I've always just done the following:

"ALLOC FI(MAIL) SYSOUT(B) WRITER(SMTP) LRECL(80) RECFM(F)"

Then open, write to it, close it, and free it; repeat.

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, May 15, 2020 4:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Looking for clarification/guidance on SMTP DD FREE/SPIN

[External Email. Exercise caution when clicking links or opening attachments.]

I am designing a long-running Rexx program that will from time to time generate 
an e-mail via the SMTP server. The idea is to allocate a DD
SYSOUT=(B,SMTP) and write the SMTP commands to it. I've never done that before 
so I have some questions:

- Am I correct in my assumption that I will have to "spin" the dataset before 
the SMTP server will pick it up?
- Assuming Yes to the first question, am I correct (a.) that 
FREE=CLOSE,SPIN=UNALLOC on the DD will get the records over to SMTP on EXECIO 
(FINIS; but that (b.) at that point the DD "no longer exists" -- that I will 
get an error if I try to open it again? (Recall the program is "long-running" 
and needs to generate multiple e-mails "from time to time."
They need to go out more or less as created, not in a big batch later on.)
- Not a huge deal if so, I guess. I can use BPXWDYN to allocate my DD again and 
again rather than JCL. Anyone have any better ideas?

Thanks. Outside-the-above-box suggestions cheerfully considered. I'm pretty 
much set on Rexx, e-mails, and "long-running with multiple e-mails from time to 
time" but will consider other possibilities.

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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

Looking for clarification/guidance on SMTP DD FREE/SPIN

[Charles Mills]

I am designing a long-running Rexx program that will from time to time
generate an e-mail via the SMTP server. The idea is to allocate a DD
SYSOUT=(B,SMTP) and write the SMTP commands to it. I've never done that
before so I have some questions:

- Am I correct in my assumption that I will have to "spin" the dataset
before the SMTP server will pick it up?
- Assuming Yes to the first question, am I correct (a.) that
FREE=CLOSE,SPIN=UNALLOC on the DD will get the records over to SMTP on
EXECIO (FINIS; but that (b.) at that point the DD "no longer exists" -- that
I will get an error if I try to open it again? (Recall the program is
"long-running" and needs to generate multiple e-mails "from time to time."
They need to go out more or less as created, not in a big batch later on.)
- Not a huge deal if so, I guess. I can use BPXWDYN to allocate my DD again
and again rather than JCL. Anyone have any better ideas? 

Thanks. Outside-the-above-box suggestions cheerfully considered. I'm pretty
much set on Rexx, e-mails, and "long-running with multiple e-mails from time
to time" but will consider other possibilities.

Charles

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

CL/ / Supersession

[Steve Beaver]

A few months ago I was asked/assigned a take to convert from NVAS to
CL/Supersession 2.1 since NVAS is EOL.

 

After a couple days and some discussions, we found out that CLSS 2.1 did not
support TCPIP Secure Sockets.

I put in an RFE #141211 and I just looked and its under development.  Now as
to how long

The development is going to take and what the PMR is going to be I just
don't know at this

Time.

 

I am hoping later this summer

 

Steve Beaver

 


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

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Wayne Bickerdike]

AGILE! Never complete Any design before you crash and burn with eons of
speculation.  Just been involved in a similar debacle. At least I'm paid by
the hour.
Once more to the drawing board. We can share the crayons!

On Sat, May 16, 2020, 05:26 Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> As promised, I can now give you the reason my co-worker needs to get file
> size information, since it is not particularly proprietary but just part of
> a generic application design.  Not commenting here (or seeking any comments
> either!  No flames please!) on whether it is a good or a bad design, just
> relaying the general story to you.
>
> I was wrong in my statement that it was a batch COBOL need.  My co-worker
> told me today that the requirement is for a CICS COBOL program to pass the
> file size for a dynamically configurable file name in a communications area
> to a generalized CICS subroutine (written and maintained by another team)
> that will send the file to a non-z/OS system.
>
> Apparently the contents and size of the files to be sent can change
> independently of CICS activity during the business day.  They are VSAM
> files with fixed-length records, so if SHOWCB information can be
> interrogated in CICS (possibly on an Open TCB) they should be able to
> calculate a reasonably accurate file size from that info.
>
> Why the generalized send subroutine needs or wants file size information
> is not in my co-worker's control.  He was just told that it is a required
> field in the communications area.  I strongly suspect that any more detail
> than that will be of a proprietary nature and thus not possible to discuss
> publicly.
>
> Thanks again for all your comments and suggestions.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Farley, Peter x23353
> Sent: Thursday, May 14, 2020 4:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there any z/OS API to get byte file size for non-VSAM,
> non-zFS, non-database files?
>
> EXTERNAL EMAIL
>
> Gentle listers, it's not that big a deal.  As to why my co-worker wants
> that information or what they think they need to do with it, I do not know
> nor did I think to ask, as it was just phrased as "can I get this
> information from a batch COBOL program?".  And I did not have the luxury of
> time to delve further into the subject as I have my own urgent priorities
> to deal with.
>
> As to the intended use of the information, if my co-worker is permitted to
> share that with me I'll share it here.
>
> In the meantime, my original question is answered: There is no easily
> callable API (bar LISTDSI from Rexx, FSVO "easy") available to provide that
> information for such files, as I surmised based on my own experience and as
> I initially replied to my co-worker.
>
> Thank you.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Paul Gilmartin
> Sent: Thursday, May 14, 2020 3:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there any z/OS API to get byte file size for non-VSAM,
> non-zFS, non-database files?
>
> On Thu, 14 May 2020 18:52:09 +, Gerhard adam wrote:
> >
> >   It is easy to say that a COBOL program needs to “know” this but it
> is nonsense since there is nothing a COBOL program can do with this info.
> >
> It could print it in a report.
>
> I suspect cultural familiarity, the complement of a presentation I
> attended circa 1980 where IBM was selling a then-innovative online
> service.  The presenter said the base subscription entitled the customer to
> one megabyte of storage.  Question from the
> audience:
> "How much is that in cylinders?"
>
> Of course, it depends.  1.75 cylinders.  Someone with a different
> background might have been familiar with 1.36 floppy disks.
>
> >If it turns out to really be necessary then a subroutine can be written
> >(as it has been done for decades) to provide this information. If the
> >question is simply to bitch about why z/OS does do this automatically
> >via a call or something then the complaint is directed to the wrong
> >group
> >
> Keep your data in zFS.  Then "ls -l" gives the answer immediately.
>
> How readily can COBOL access zFS files.  BPXWDYN should make it routine.
>
> --
>
> 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: 

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Farley, Peter x23353]

As promised, I can now give you the reason my co-worker needs to get file size 
information, since it is not particularly proprietary but just part of a 
generic application design.  Not commenting here (or seeking any comments 
either!  No flames please!) on whether it is a good or a bad design, just 
relaying the general story to you.

I was wrong in my statement that it was a batch COBOL need.  My co-worker told 
me today that the requirement is for a CICS COBOL program to pass the file size 
for a dynamically configurable file name in a communications area to a 
generalized CICS subroutine (written and maintained by another team) that will 
send the file to a non-z/OS system.

Apparently the contents and size of the files to be sent can change 
independently of CICS activity during the business day.  They are VSAM files 
with fixed-length records, so if SHOWCB information can be interrogated in CICS 
(possibly on an Open TCB) they should be able to calculate a reasonably 
accurate file size from that info.

Why the generalized send subroutine needs or wants file size information is not 
in my co-worker's control.  He was just told that it is a required field in the 
communications area.  I strongly suspect that any more detail than that will be 
of a proprietary nature and thus not possible to discuss publicly.

Thanks again for all your comments and suggestions.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Thursday, May 14, 2020 4:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

EXTERNAL EMAIL

Gentle listers, it's not that big a deal.  As to why my co-worker wants that 
information or what they think they need to do with it, I do not know nor did I 
think to ask, as it was just phrased as "can I get this information from a 
batch COBOL program?".  And I did not have the luxury of time to delve further 
into the subject as I have my own urgent priorities to deal with.

As to the intended use of the information, if my co-worker is permitted to 
share that with me I'll share it here.

In the meantime, my original question is answered: There is no easily callable 
API (bar LISTDSI from Rexx, FSVO "easy") available to provide that information 
for such files, as I surmised based on my own experience and as I initially 
replied to my co-worker.

Thank you.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, May 14, 2020 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

On Thu, 14 May 2020 18:52:09 +, Gerhard adam wrote: 
>
>   It is easy to say that a COBOL program needs to “know” this but it is 
> nonsense since there is nothing a COBOL program can do with this info. 
>
It could print it in a report.

I suspect cultural familiarity, the complement of a presentation I attended 
circa 1980 where IBM was selling a then-innovative online service.  The 
presenter said the base subscription entitled the customer to one megabyte of 
storage.  Question from the
audience:
"How much is that in cylinders?"

Of course, it depends.  1.75 cylinders.  Someone with a different background 
might have been familiar with 1.36 floppy disks.

>If it turns out to really be necessary then a subroutine can be written 
>(as it has been done for decades) to provide this information. If the 
>question is simply to bitch about why z/OS does do this automatically 
>via a call or something then the complaint is directed to the wrong 
>group
>   
Keep your data in zFS.  Then "ls -l" gives the answer immediately.

How readily can COBOL access zFS files.  BPXWDYN should make it routine.

--

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

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 

Re: Does allocating an HFS or zFS erase all existing data?intervals formatted?

[Mike Schwab]

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idai200/da6i2118.htm
Discussion on Speed / Recovery option.

On Fri, May 15, 2020 at 5:34 PM Seymour J Metz  wrote:
>
> Do you have something that I can cite for that, preferably something that all 
> wiki readers can look at?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Mike Schwab [mike.a.sch...@gmail.com]
> Sent: Friday, May 15, 2020 1:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Does allocating an HFS or zFS erase all existing data?intervals 
> formatted?
>
> All VSAM datasets including Linear are formatted when created.  The
> disk space used is not allocated to any other datasets.  Previous data
> left by deleted datasets is usually left in place (erase on delete is
> an option but not used frequently) but frequently overwritten in a
> short time so restoring a deleted data set is almost always
> impossible.
>
> On Fri, May 15, 2020 at 4:25 PM Seymour J Metz  wrote:
> >
> > I want to edit the wiki article [[Disk formatting]] to clarify the 
> > statement "s a general rule,[nb 1] formatting a disk erases most if not all 
> > existing data on the disk medium". Normally I would consult the logic 
> > manuals :-(
> >
> > When you allocate an HFS or linear data set, does AMS preformat all of the 
> > tracks? When you format a zFS, does that force formatting of all tracks? 
> > Can you provide references that I can cite for the answers?
> >
> > Thanks.
> >
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > --
> > 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
>
> --
> 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: USS: su: User ID "SH" does not exist

[Tony Harminc]

On Fri, 15 May 2020 at 12:38, Seymour J Metz  wrote:
>
> I thought that you could turn off TSO recognition of semicolon with
PROFILE or TERMINAL but, no, you can't. I'm not sure what happens if CLIST
or REXX code passes a semicolon. OTOH, TSO will accept a semicolon in a
quoted string.

Semicolon is not a command separator in TSO; there is no facility to put
more than one command on a line. Semicolon does end the command, and
behaves a lot like a trailing /* does.
 READY
listd test.asm ; any old junk
 C702TOH.TEST.ASM
 --RECFM-LRECL-BLKSIZE-DSORG
   FB803120PO
 --VOLUMES--
   A3USR3
 READY
send 'Hello' user(*) ;  some stuff
 Hello C702TOH
 READY
send 'Hello' user(*) some stuff
 IKJ56712I INVALID KEYWORD, SOME
 IKJ56703A REENTER THIS OPERAND - (I hit enter here)
 IKJ56712I INVALID KEYWORD, STUFF
 IKJ56703A REENTER THIS OPERAND - (I hit enter here)
 Hello C702TOH
 READY

Of course ISPF has very different behaviours, and it doesn't help that so
many people think that ISPF *is* TSO.

Tony H.

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

OoRexx (was: ... byte file size ... ?)

[Paul Gilmartin]

On Fri, 15 May 2020 18:52:24 +, Seymour J Metz wrote:

>Well, I use OREXX on OS/2, so oorexx is a natural on Linux. The one 
>disadvantage is that oorexx hasn't picked up all of the ANSI enhancements; but 
>then, neither has TSO/E.
> 
What does it lack?

And one of my favorites: is it timezone savvy?  That might be
outboarded with calls to C RTL.

Hmmm.  Apparently, according to:
https://www.oorexx.org/docs/rexxref/x23579.htm

-- gil

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

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Seymour J Metz]

Well, I use OREXX on OS/2, so oorexx is a natural on Linux. The one 
disadvantage is that oorexx hasn't picked up all of the ANSI enhancements; but 
then, neither has TSO/E.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Friday, May 15, 2020 2:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

That's a Rexx I never tried, probably out of fear of the "OO"
designation :)

On 5/15/2020 11:11 AM, Seymour J Metz wrote:
> EXECIO is in the hostemu environment of oorexx.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Tom Brennan [t...@tombrennansoftware.com]
> Sent: Friday, May 15, 2020 12:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, 
> non-zFS, non-database files?
>
> That's one of my favorite things about Rexx (although I hear EXECIO is
> not really part of Rexx and I know it's not in PC versions like Regina).
>I've used it on some very large datasets, and yeah, you wait a bit for
> the data to load.  But once data is in the stem variable, things are
> really fast and (another favorite of mine) you can easily do control
> breaks by peeking 1 record ahead or back.
>
> On 5/15/2020 9:12 AM, Charles Mills wrote:
>> Right, it appears to be magic -- "just say EXECIO and presto there's the 
>> record count in STEM.0" -- but under the covers it is reading through the 
>> whole dataset and counting.
>>
>> Rexx is all 31-bit, right? So the limit would presumably be something in the 
>> 1 to 2 GB range. That is not an implausibly huge dataset. 1GB is what? 800 
>> cylinders or somewhat more, depending on blocking, short tracks, etc.?
>>
>> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

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

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

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Charles Mills]

But everything to do with how big a stem variable array it can build.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Friday, May 15, 2020 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

A program's AMODE has nothing much to do with how high it can count.

sas


On Fri, May 15, 2020 at 1:23 PM Seymour J Metz  wrote:

> It is well documented, albeit with minor errors
>
> Yes, I believe that it is still 31 bit. Another reason to port oorexx .
>
>

--
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: z/Aware

[Parwez Hamid]

In my previous reply I forgot to mention that for zEC12, zBC12, z13 and z13s 
was delivered as 'firmware'. I believe, its now delivered as 'software' 
appliance feature with IBM Operations Analytics

https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=897/ENUS218-165=AN=CA#hardx
IBM Z Operations Analytics, V3.2, formerly known as IBM Operations Analytics 
for z Systems, delivers powerful operational insights across industry-leading 
analytics 
platforms
218-165,
www-01.ibm.com


Regards

Parwez Hamid​


From: IBM Mainframe Discussion List  on behalf of 
Steve Beaver 
Sent: 15 May 2020 16:01
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: z/Aware

I just got z/Aware dumped into my LAP to install and configure



Does anyone have any experience with z/Aware?








--
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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Tom Brennan]

That's a Rexx I never tried, probably out of fear of the "OO" 
designation :)


On 5/15/2020 11:11 AM, Seymour J Metz wrote:

EXECIO is in the hostemu environment of oorexx.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Friday, May 15, 2020 12:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

That's one of my favorite things about Rexx (although I hear EXECIO is
not really part of Rexx and I know it's not in PC versions like Regina).
   I've used it on some very large datasets, and yeah, you wait a bit for
the data to load.  But once data is in the stem variable, things are
really fast and (another favorite of mine) you can easily do control
breaks by peeking 1 record ahead or back.

On 5/15/2020 9:12 AM, Charles Mills wrote:

Right, it appears to be magic -- "just say EXECIO and presto there's the record 
count in STEM.0" -- but under the covers it is reading through the whole dataset and 
counting.

Rexx is all 31-bit, right? So the limit would presumably be something in the 1 
to 2 GB range. That is not an implausibly huge dataset. 1GB is what? 800 
cylinders or somewhat more, depending on blocking, short tracks, etc.?

Charles


--
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: DFSMS Move Dataset

[David Spiegel]

Hi Paul,
A bit of advice (I've been using DFSMSdss for 30+ years).

Unless not possible, ALWAYS obtain your list of Datasets to be 
processed, via Logical criteria.

(Do not, unless you have to, use Physical criteria).
The difference between them is that Physical criteria are generated by 
coding INDDNAME or INDYNAM.

(If you code LOGINDDNAME or LOGINDYNAM it's Logical.)

You will likely hear that Physical means Full Volume and that Logical 
means by Dataset.

This statement is ABSOLUTELY false.

One more thing ... always code OPT(4) to read a Cylinder at a time.

Good luck!

Regards,
David

On 2020-05-15 13:39, esst...@juno.com wrote:

Hello.
Does IBM (DFSMS) have a utility that will move VSAM and/or non-VSAM dataset  to 
a
different VOLUME ?
.
Paul D'Angelo
*
*
*

--
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: z/Aware

[Parwez Hamid]

These 2 docs should be a good starting point:

Advanced Workload Analysis Reporter (IBM zAware) Guide - SC27-2632

and

http://www.redbooks.ibm.com/abstracts/sg248070.html?Open
Extending z/OS System Management Functions with IBM zAware | IBM 
Redbooks
This IBM® Redbooks® publication explains the capabilities of the IBM System z® 
Advanced Workload Analysis Reporter (IBM zAware), and shows how you can use it 
as an integral part of your existing System z management tools.
www.redbooks.ibm.com


Regards

Parwez Hamid​


From: IBM Mainframe Discussion List  on behalf of 
Steve Beaver 
Sent: 15 May 2020 16:01
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: z/Aware

I just got z/Aware dumped into my LAP to install and configure



Does anyone have any experience with z/Aware?








--
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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Seymour J Metz]

> A program's AMODE has nothing much to do with how high it can count.

K3wl! Who claimed that it did?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Smith [sasd...@gmail.com]
Sent: Friday, May 15, 2020 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

A program's AMODE has nothing much to do with how high it can count.

sas


On Fri, May 15, 2020 at 1:23 PM Seymour J Metz  wrote:

> It is well documented, albeit with minor errors
>
> Yes, I believe that it is still 31 bit. Another reason to port oorexx .
>
>

--
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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Seymour J Metz]

EXECIO is in the hostemu environment of oorexx.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Friday, May 15, 2020 12:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

That's one of my favorite things about Rexx (although I hear EXECIO is
not really part of Rexx and I know it's not in PC versions like Regina).
  I've used it on some very large datasets, and yeah, you wait a bit for
the data to load.  But once data is in the stem variable, things are
really fast and (another favorite of mine) you can easily do control
breaks by peeking 1 record ahead or back.

On 5/15/2020 9:12 AM, Charles Mills wrote:
> Right, it appears to be magic -- "just say EXECIO and presto there's the 
> record count in STEM.0" -- but under the covers it is reading through the 
> whole dataset and counting.
>
> Rexx is all 31-bit, right? So the limit would presumably be something in the 
> 1 to 2 GB range. That is not an implausibly huge dataset. 1GB is what? 800 
> cylinders or somewhat more, depending on blocking, short tracks, etc.?
>
> Charles

--
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: BPXBATCH . . . odd PATH

[Kirk Wolf]

Tip:   this is one way to trace your login profiles:

//SHELL   EXEC PGM=BPXBATCH,PARM='PGM /bin/sh -Lx'
//STDIN   DD DUMMY
//STDOUT  DD SYSOUT=*
//STDERR  DD SYSOUT=*
//



On Fri, May 15, 2020 at 12:27 PM Seymour J Metz  wrote:

> I thought that ~/.profile runs after /etc/profile, and thus takes
> precedence. So if you export $PATH, that's the value you should see.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Jon Bathmaker [jon.bathma...@sys1consulting.com]
> Sent: Friday, May 15, 2020 1:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: BPXBATCH . . . odd PATH
>
> Hi All,
>
> When I run a BPXBATCH job using this:
> STDPARM  SH echo $PATH;
>   su
> I get the following results which imply that when the shell is invoked
> for the Superuser it's using an old path that it found . . .
> somewhere.   The PATH in STDOUT came from my .profile.   The profile in
> STDERR does not match the PATH from /etc/profile and there is no
> etc/suid_profile. So where *is* he getting that bad PATH?   Any help
> would be much appreciated.  Thanks.
>
> STDERR /bin:/usr/lpp/java/J1.4_64/bin/:/u/#T95JXB/scripts: FSUM7351 not
> found
> STDOUT /bin/:/usr/sbin/:/usr/lpp/java/J8.0_64/bin/:/u/#T95JXB/scripts/
>
>
> Best regards,
>
> Jon Bathmaker
>
> z/OS Systems Programmer
>
> 519-577-9661
>
>
> --
> 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: DFSMS Move Dataset

[Steve Smith]

DFDSS COPY with DELETE is a move, and you don't need to make an unnecessary
copy or run two commands.

sas

On Fri, May 15, 2020 at 1:48 PM Lizette Koehler 
wrote:

> Depends on what you mean by MovE
>
> I use DFHSM Migrate/Recall to move a dataset from a volume
>
> I can use DFDSS to dump with delete then restore with Catalog
>
> The ISMF Panels also have some options.
>
> Do you have any other tools like FDR?
>
> Lizette
>
>

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

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Steve Smith]

A program's AMODE has nothing much to do with how high it can count.

sas


On Fri, May 15, 2020 at 1:23 PM Seymour J Metz  wrote:

> It is well documented, albeit with minor errors
>
> Yes, I believe that it is still 31 bit. Another reason to port oorexx .
>
>

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

Re: DFSMS Move Dataset

[Ed Jaffe]

On 5/15/2020 10:39 AM, esst...@juno.com wrote:

Hello.
Does IBM (DFSMS) have a utility that will move VSAM and/or non-VSAM dataset  to 
a
different VOLUME ?



DSS


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



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: DFSMS Move Dataset

[Lizette Koehler]

Depends on what you mean by MovE

I use DFHSM Migrate/Recall to move a dataset from a volume 

I can use DFDSS to dump with delete then restore with Catalog 

The ISMF Panels also have some options.

Do you have any other tools like FDR?

Lizette

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
esst...@juno.com
Sent: Friday, May 15, 2020 10:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFSMS Move Dataset

Hello.
Does IBM (DFSMS) have a utility that will move VSAM and/or non-VSAM dataset
to a different VOLUME ?
.
Paul D'Angelo
*
*
* 

--
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: USS: su: User ID "SH" does not exist

[Seymour J Metz]

Or they have other fish to fry. I doubt that IBM is immune to the COVID-19 
chaos.

"Defending BPXBATCH is not in my job description."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Friday, May 15, 2020 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

On Fri, 15 May 2020 16:38:04 +, Seymour J Metz wrote:

>I thought that you could turn off TSO recognition of semicolon with PROFILE or 
>TERMINAL but, no, you can't. I'm not sure what happens if CLIST or REXX code 
>passes a semicolon. OTOH, TSO will accept a semicolon in a quoted string.
>
I couldn't turn it off for ISPF.  I set it to '¾' and hope I never need it.

>The TSO command is OMVS and it is documented in z/OS UNIX System Services 
>Command Reference.
>
"TSO SH" causes TSO TMP to execute an "SH" command, and I can't
find documentation of the latter.

IBM representatives have been conspicuously silent on two
ongoing related threads.  Perhaps they recognize BPXBATCH
is indefensible.

>
>From: Paul Gilmartin
>Sent: Friday, May 15, 2020 12:22 PM (in whatever timezone)
>
>On Fri, 15 May 2020 14:02:25 +, Seymour J Metz wrote:
>
>>Semicolon is a separator for TSO SH as well, but you have to keep TSO from 
>>recognizing it.

-- gil

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

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

Re: DFSMS Move Dataset

[Gerhard adam]

  
  
  

DFSMSdss will do and it can also be invoked from ISMF where a filter 
list can be build for the files to be moved



Get Outlook for iOS

  




On Fri, May 15, 2020 at 10:41 AM -0700, "esst...@juno.com"  
wrote:










Hello.
Does IBM (DFSMS) have a utility that will move VSAM and/or non-VSAM dataset  to 
a
different VOLUME ?
.
Paul D'Angelo
*
*
*

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

DFSMS Move Dataset

[esst...@juno.com]

Hello.
Does IBM (DFSMS) have a utility that will move VSAM and/or non-VSAM dataset  to 
a
different VOLUME ?
.
Paul D'Angelo
*
*
*

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

Re: Does allocating an HFS or zFS erase all existing data?intervals formatted?

[Seymour J Metz]

Do you have something that I can cite for that, preferably something that all 
wiki readers can look at?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mike Schwab [mike.a.sch...@gmail.com]
Sent: Friday, May 15, 2020 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Does allocating an HFS or zFS erase all existing data?intervals 
formatted?

All VSAM datasets including Linear are formatted when created.  The
disk space used is not allocated to any other datasets.  Previous data
left by deleted datasets is usually left in place (erase on delete is
an option but not used frequently) but frequently overwritten in a
short time so restoring a deleted data set is almost always
impossible.

On Fri, May 15, 2020 at 4:25 PM Seymour J Metz  wrote:
>
> I want to edit the wiki article [[Disk formatting]] to clarify the statement 
> "s a general rule,[nb 1] formatting a disk erases most if not all existing 
> data on the disk medium". Normally I would consult the logic manuals :-(
>
> When you allocate an HFS or linear data set, does AMS preformat all of the 
> tracks? When you format a zFS, does that force formatting of all tracks? Can 
> you provide references that I can cite for the answers?
>
> Thanks.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> --
> 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

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

Re: Does allocating an HFS or zFS erase all existing data?intervals formatted?

[David Spiegel]

Hi Mike,
You said: "...  All VSAm Datasets including Linear are formatted when 
created ...".

Is this true for ESDSs?
Where is this documented?

Thanks and regards,
David

All VSAM datasets including Linear are formatted when created

On 2020-05-15 13:14, Mike Schwab wrote:

All VSAM datasets including Linear are formatted when created.  The
disk space used is not allocated to any other datasets.  Previous data
left by deleted datasets is usually left in place (erase on delete is
an option but not used frequently) but frequently overwritten in a
short time so restoring a deleted data set is almost always
impossible.

On Fri, May 15, 2020 at 4:25 PM Seymour J Metz  wrote:

I want to edit the wiki article [[Disk formatting]] to clarify the statement "s a 
general rule,[nb 1] formatting a disk erases most if not all existing data on the disk 
medium". Normally I would consult the logic manuals :-(

When you allocate an HFS or linear data set, does AMS preformat all of the 
tracks? When you format a zFS, does that force formatting of all tracks? Can 
you provide references that I can cite for the answers?

Thanks.



--
Shmuel (Seymour J.) Metz
https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7C74a32c4b87de48c2be2c08d7f8f38371%7C84df9e7fe9f640afb435%7C1%7C0%7C637251597081119599sdata=nFq8774EHZTWnk8RfMeRQIFWs8qBqBpq5TQ1VvgGuy4%3Dreserved=0

--
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: BPXBATCH . . . odd PATH

[Seymour J Metz]

I thought that ~/.profile runs after /etc/profile, and thus takes precedence. 
So if you export $PATH, that's the value you should see.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Bathmaker [jon.bathma...@sys1consulting.com]
Sent: Friday, May 15, 2020 1:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BPXBATCH . . . odd PATH

Hi All,

When I run a BPXBATCH job using this:
STDPARM  SH echo $PATH;
  su
I get the following results which imply that when the shell is invoked
for the Superuser it's using an old path that it found . . .
somewhere.   The PATH in STDOUT came from my .profile.   The profile in
STDERR does not match the PATH from /etc/profile and there is no
etc/suid_profile. So where *is* he getting that bad PATH?   Any help
would be much appreciated.  Thanks.

STDERR /bin:/usr/lpp/java/J1.4_64/bin/:/u/#T95JXB/scripts: FSUM7351 not
found
STDOUT /bin/:/usr/sbin/:/usr/lpp/java/J8.0_64/bin/:/u/#T95JXB/scripts/


Best regards,

Jon Bathmaker

z/OS Systems Programmer

519-577-9661


--
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: USS: su: User ID "SH" does not exist

[Paul Gilmartin]

On Fri, 15 May 2020 12:04:42 -0500, Kirk Wolf wrote:

>On Fri, May 15, 2020 at 11:44 AM Seymour J Metz wrote:
>
>Which documentations describes the SH concatenation for other than
>> instream? Also, where in the documentation does it say that it inserts
>> whitespace after each record?
>>
>You are right.  IBM doesn't really document what happens other than
>instream.   They do document how records are concatenated with a blank
>separator.
>
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxa400/gfdstdparm.htm
>
>"For in-stream data sets: with the SH option, trailing blanks are not
>truncated. Records in in-stream data sets are concatenated with blanks as
>separator characters, and the string remaining after the SH token is passed
>as a single argument to a /bin/sh -c command. For the PGM option, the
>string is divided not only at line boundaries but also at blanks within a
>line."
>
>It's astounding that IBM implemented and partially documented STDPARM as an
>additional layer of suckage rather than just fixing BPXBATCH.Look only
>at how many problems that people have on mvs-oe and ibm-main as your
>evidence.
>
But then it would compete with AOPBATCH which is part of a separately
priced offering.

Nowadays, customers have the alternative of PARMDD, with very
similar deficiencies.

>I wonder: can you open an RFE and attach a complete 1000 line C program? :-)
>
Is someone giving one away?  Who'd maintain it?

IBM's OCC is uncomfortable with that sort of thing, for both IP and
consequential damage concerns.  They were probably fastidious with
Rocket.

>> The treatment of semicolons is bog standard, but it wouldn't hurt to spell 
>> it out.
>>
But then we couldn't have such entertaining discussions of it in these fora.

-- gil

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

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Seymour J Metz]

It is well documented, albeit with minor errors

Yes, I believe that it is still 31 bit. Another reason to port oorexx .


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Friday, May 15, 2020 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

Right, it appears to be magic -- "just say EXECIO and presto there's the record 
count in STEM.0" -- but under the covers it is reading through the whole 
dataset and counting.

Rexx is all 31-bit, right? So the limit would presumably be something in the 1 
to 2 GB range. That is not an implausibly huge dataset. 1GB is what? 800 
cylinders or somewhat more, depending on blocking, short tracks, etc.?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Bickerdike
Sent: Thursday, May 14, 2020 11:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

> EXECIO in REXX will give you the record count in stem zero

I believe only by reading the entire file.

On Fri, May 15, 2020 at 8:02 AM Charles Mills  wrote:

> > EXECIO in REXX will give you the record count in stem zero
>
> I believe only by reading the entire file.
>
> Charles
>

Agree Charles. It's sort of hidden and would need a large memory allocation
for the stem.

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

BPXBATCH . . . odd PATH

[Jon Bathmaker]

Hi All,

When I run a BPXBATCH job using this:
STDPARM  SH echo $PATH;
 su
I get the following results which imply that when the shell is invoked 
for the Superuser it's using an old path that it found . . .  
somewhere.   The PATH in STDOUT came from my .profile.   The profile in 
STDERR does not match the PATH from /etc/profile and there is no 
etc/suid_profile. So where *is* he getting that bad PATH?   Any help 
would be much appreciated.  Thanks.


STDERR /bin:/usr/lpp/java/J1.4_64/bin/:/u/#T95JXB/scripts: FSUM7351 not 
found

STDOUT /bin/:/usr/sbin/:/usr/lpp/java/J8.0_64/bin/:/u/#T95JXB/scripts/


Best regards,

Jon Bathmaker

z/OS Systems Programmer

519-577-9661


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

Re: Does allocating an HFS or zFS erase all existing data?intervals formatted?

[Mike Schwab]

All VSAM datasets including Linear are formatted when created.  The
disk space used is not allocated to any other datasets.  Previous data
left by deleted datasets is usually left in place (erase on delete is
an option but not used frequently) but frequently overwritten in a
short time so restoring a deleted data set is almost always
impossible.

On Fri, May 15, 2020 at 4:25 PM Seymour J Metz  wrote:
>
> I want to edit the wiki article [[Disk formatting]] to clarify the statement 
> "s a general rule,[nb 1] formatting a disk erases most if not all existing 
> data on the disk medium". Normally I would consult the logic manuals :-(
>
> When you allocate an HFS or linear data set, does AMS preformat all of the 
> tracks? When you format a zFS, does that force formatting of all tracks? Can 
> you provide references that I can cite for the answers?
>
> Thanks.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> --
> 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: USS: su: User ID "SH" does not exist

[Kirk Wolf]

On Fri, May 15, 2020 at 11:44 AM Seymour J Metz  wrote:

Which documentations describes the SH concatenation for other than
> instream? Also, where in the documentation does it say that it inserts
> whitespace after each record?
>
>
You are right.  IBM doesn't really document what happens other than
instream.   They do document how records are concatenated with a blank
separator.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxa400/gfdstdparm.htm

"For in-stream data sets: with the SH option, trailing blanks are not
truncated. Records in in-stream data sets are concatenated with blanks as
separator characters, and the string remaining after the SH token is passed
as a single argument to a /bin/sh -c command. For the PGM option, the
string is divided not only at line boundaries but also at blanks within a
line."

It's astounding that IBM implemented and partially documented STDPARM as an
additional layer of suckage rather than just fixing BPXBATCH.Look only
at how many problems that people have on mvs-oe and ibm-main as your
evidence.

I wonder: can you open an RFE and attach a complete 1000 line C program? :-)



> The treatment of semicolons is bog standard, but it wouldn't hurt to spell
> it out.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Kirk Wolf [k...@wolf-associates.com]
> Sent: Friday, May 15, 2020 12:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: USS: su: User ID "SH" does not exist
>
> Jack,
> I would disagree with your explanation of why BPXBATCH works so poorly ;-)
>
> In the OP's example, DD STDPARM is used to construct a single PARM string
> that ends up getting passed to BPXBATCH.
> What BPXBATCH does is look at the leading "SH"  in it's PARM and then pass
> the rest of the string as the argument to "/bin/sh -c"
>
> STDPARM washes away the record boundaries (see the doc).  The semicolons
> are required at the end of DD:STDPARM records so that this single argument
> to "/bin/sh -c " can  be broken into multiple shell commands.   The whole
> thing is an ugly hack.
>
> FWIW, I've been using the shell in z/OS batch since 2007 with its stdin
> coming from //STDIN DD *.   And yes, I know what here documents are.   I
> just don't use  brain dead BPXBATCH.
>
> Kirk Wolf
> Dovetailed Technologies
>
> http://secure-web.cisco.com/1DDthcclBqpmyDPhXkwTl61-tucNWumiSPx4_aYKVPrVxNfeoPCrbBfnnG0alInEOrfKy2hfdhtNsJX0xkzozZbLNC4sEZpSyV8iB9cYm44BuNTg4l413TmpY-hPI9kvd9bEhJE2O6jUP5A07KotfYXVXevpgJ_SJXXF-ivOt8BCRRbAnRFKSl_4rgg_7hOFTJazOknkNLje7QaKMlvqf7E7qG_5YXdL3wCRLvPF8PHex1cN7yzYo6pXqmogp8RufthS8IOFnIsz65wS-psI3UhNQI_xzQ0aKGgrFpUuLajFp-EvfXZ8UbWHP5LBnVEyyyQl3wwS0Ra_SaX9fS8Fek9qIHRtyxDAucSxDCo7CMYDxe9GtsfU3rkuwNorljA-5qO6yGQZc049LnyIv0mtxe-i8CZBCpUkIUVTonlffsfncgtrSzuONGrpR4o_4dqy2/http%3A%2F%2Fdovetail.com
>
> https://secure-web.cisco.com/1aSsEzfhdxsxGQOHzXtwj9y0ebXkNUzDJfewjX3pR6Fd4beP-RSZu0r_mGMErxN1fXuGAvcy8_tUYdci2FYwScWxvvSyTJLYVKb-DV_oDBH2-KLpQSgikqVtTB9xoROwUk4zGJRud0IEaZIeY_lwCaoS5XDsiVmIRKS03PhsUX65ETWqCmSFkA7dSiEUflO1g9KWuIPd1y-9Kz5KbEC34bcnfj_UpmPG0YHigxjbdV_zpjabwBWBytj_W7dr4ugL8Q7IaD472bZgZbMsCOXuyhmohBE5nVKhOorv6XNDVWO0eFl1-Zp5gmpAuzntiQaWBUgvDD5B9WUpC0dDdBA3Xhih7kRaG6waWl_qVVkr4mzcFqRmivXDmYVYfLpZnuqVxSh4-9AC7bd9Icrn2fFTCoHzczsJPN8P-16n_BjxnRA72LkIQx7xIWw8qJv_hkPnR/https%3A%2F%2Fdovetail.com%2Fproducts%2Fcozbatch.html
>
> On Fri, May 15, 2020 at 10:12 AM Jack J. Woehr  wrote:
>
> > On 5/15/20 8:51 AM, Seymour J Metz wrote:
> > > I understand why they parse pgm and sh differently. What I don't
> > understand is why instream data should be treated differently from other
> > datasets.
> >
> > Because it's easier to present to the Unix System Services environment
> > that way?
> > Unix is stream oriented, not record oriented, and shell syntax is molded
> > to that.
> > There are shell features like "here documents" (google it) which you've
> > probably never used that would get broken if input to the USS shell got
> > arbitrarily broken into lines to suit the flavor of MVS/TSO/JES
> >
> > --
> > Jack J. Woehr # Science is more than a body of knowledge. It's a way
> of
> >
> http://secure-web.cisco.com/1gESWY33ldhCr_PLmzxOYS5kRZsH5Jydluqvcg3t9MPdfU6x1ydUzY2STwg49U53joXvW9MqU7qeVG1rzBwhnCuzzvAp06_kN0hg-HOY48DYj5sjsGbyf4Y4o1u16bdiQTQwbPH7w4NZAwoOlQT7Y6gPqz_nehnFJinPk_xF5VqBR8HOH2yWGGOdb81ML09T3VUzHm0dbK1UfatdI1MsMcX0zNOiUAHui4VwiwH2EraXz6ZBdNBjruuZ13Nm8jAFkKRFpphvG5odt_angEbyEh12MMa-9JqD-YHvT_Ro1Y-A4SmvxKszGzOeN8DzrG6ifDRlGLu69L6FrN-LoH1-duTRNa4AlO-4AOOULkrGB2d-1kj5XLBR0npsMO3BZVSDwuP_HZoeoJZcgJ1O4NDZR91cSsyxuctt7pi9czx4a3KNLPnU8eQHIKBg8qFkmLjc0/http%3A%2F%2Fwww.well.com%2F%7Ejax
> # thinking, a way of skeptically interrogating the
> > universe
> >
> 

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Paul Gilmartin]

On Fri, 15 May 2020 11:39:59 -0500, Kirk Wolf wrote:

>Having personally spent a large amount of time dealing with this issue,
>what I can tell you is that for non-VSAM data sets that the best that you
>can do in most cases (without actually reading the data set) is to look at
>the DSCBs  to get the last used TTR and then calculate an estimate of the
>data set size based on the recfm and blksize.There are some special
>cases, like compressed data sets where the catalog can help.
>
>It would be fantastic if somewhere you could get:
>1) the number of logical records
>
Use CMS.

>2) the total number of bytes
>
Use zFS.  (mutually exclusive with (1).)

>3) fine grained timestamp when the data set was last updated
>
FAMS has this for PDSE members.  Why is it a #$%^& trade secret
from the user when a file was updated?  (But it's visible from an NFS
client!) 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idan400/cpn2co250.htm

>4) sha256 hash of the data set
>
And whatever other metadata a customer wishes for or is
useful for web cache validation:
https://en.wikipedia.org/wiki/HTTP_ETag

-- gil

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

Re: USS: su: User ID "SH" does not exist

[Paul Gilmartin]

On Fri, 15 May 2020 16:38:04 +, Seymour J Metz wrote:

>I thought that you could turn off TSO recognition of semicolon with PROFILE or 
>TERMINAL but, no, you can't. I'm not sure what happens if CLIST or REXX code 
>passes a semicolon. OTOH, TSO will accept a semicolon in a quoted string.
>
I couldn't turn it off for ISPF.  I set it to '¾' and hope I never need it.

>The TSO command is OMVS and it is documented in z/OS UNIX System Services 
>Command Reference.
>
"TSO SH" causes TSO TMP to execute an "SH" command, and I can't
find documentation of the latter.

IBM representatives have been conspicuously silent on two
ongoing related threads.  Perhaps they recognize BPXBATCH
is indefensible.

>
>From: Paul Gilmartin
>Sent: Friday, May 15, 2020 12:22 PM (in whatever timezone)
>
>On Fri, 15 May 2020 14:02:25 +, Seymour J Metz wrote:
>
>>Semicolon is a separator for TSO SH as well, but you have to keep TSO from 
>>recognizing it.

-- gil

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

Re: USS: su: User ID "SH" does not exist

[Kirk Wolf]

Gil,

Some people hate EBCDIC, others BPXBATCH :-)

On Fri, May 15, 2020 at 11:35 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 15 May 2020 11:26:29 -0500, Kirk Wolf wrote:
> >
> >STDPARM washes away the record boundaries (see the doc).  The semicolons
> >
> What if you start each line with x'15'?
> ISPF Edit change all ';' x'15 1 1'?
>
> >are required at the end of DD:STDPARM records so that this single argument
> >to "/bin/sh -c " can  be broken into multiple shell commands.   The whole
> >thing is an ugly hack.
> >
> >FWIW, I've been using the shell in z/OS batch since 2007 with its stdin
> >coming from //STDIN DD *.   And yes, I know what here documents are.   I
> >just don't use  brain dead BPXBATCH.
> >
> How do you *really* feel about it?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Tom Brennan]

That's one of my favorite things about Rexx (although I hear EXECIO is 
not really part of Rexx and I know it's not in PC versions like Regina). 
 I've used it on some very large datasets, and yeah, you wait a bit for 
the data to load.  But once data is in the stem variable, things are 
really fast and (another favorite of mine) you can easily do control 
breaks by peeking 1 record ahead or back.


On 5/15/2020 9:12 AM, Charles Mills wrote:

Right, it appears to be magic -- "just say EXECIO and presto there's the record 
count in STEM.0" -- but under the covers it is reading through the whole dataset and 
counting.

Rexx is all 31-bit, right? So the limit would presumably be something in the 1 
to 2 GB range. That is not an implausibly huge dataset. 1GB is what? 800 
cylinders or somewhat more, depending on blocking, short tracks, etc.?

Charles


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

Re: USS: su: User ID "SH" does not exist

[Seymour J Metz]

Which documentations describes the SH concatenation for other than instream? 
Also, where in the documentation does it say that it inserts whitespace after 
each record?

The treatment of semicolons is bog standard, but it wouldn't hurt to spell it 
out.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Kirk Wolf [k...@wolf-associates.com]
Sent: Friday, May 15, 2020 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

Jack,
I would disagree with your explanation of why BPXBATCH works so poorly ;-)

In the OP's example, DD STDPARM is used to construct a single PARM string
that ends up getting passed to BPXBATCH.
What BPXBATCH does is look at the leading "SH"  in it's PARM and then pass
the rest of the string as the argument to "/bin/sh -c"

STDPARM washes away the record boundaries (see the doc).  The semicolons
are required at the end of DD:STDPARM records so that this single argument
to "/bin/sh -c " can  be broken into multiple shell commands.   The whole
thing is an ugly hack.

FWIW, I've been using the shell in z/OS batch since 2007 with its stdin
coming from //STDIN DD *.   And yes, I know what here documents are.   I
just don't use  brain dead BPXBATCH.

Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/1DDthcclBqpmyDPhXkwTl61-tucNWumiSPx4_aYKVPrVxNfeoPCrbBfnnG0alInEOrfKy2hfdhtNsJX0xkzozZbLNC4sEZpSyV8iB9cYm44BuNTg4l413TmpY-hPI9kvd9bEhJE2O6jUP5A07KotfYXVXevpgJ_SJXXF-ivOt8BCRRbAnRFKSl_4rgg_7hOFTJazOknkNLje7QaKMlvqf7E7qG_5YXdL3wCRLvPF8PHex1cN7yzYo6pXqmogp8RufthS8IOFnIsz65wS-psI3UhNQI_xzQ0aKGgrFpUuLajFp-EvfXZ8UbWHP5LBnVEyyyQl3wwS0Ra_SaX9fS8Fek9qIHRtyxDAucSxDCo7CMYDxe9GtsfU3rkuwNorljA-5qO6yGQZc049LnyIv0mtxe-i8CZBCpUkIUVTonlffsfncgtrSzuONGrpR4o_4dqy2/http%3A%2F%2Fdovetail.com
https://secure-web.cisco.com/1aSsEzfhdxsxGQOHzXtwj9y0ebXkNUzDJfewjX3pR6Fd4beP-RSZu0r_mGMErxN1fXuGAvcy8_tUYdci2FYwScWxvvSyTJLYVKb-DV_oDBH2-KLpQSgikqVtTB9xoROwUk4zGJRud0IEaZIeY_lwCaoS5XDsiVmIRKS03PhsUX65ETWqCmSFkA7dSiEUflO1g9KWuIPd1y-9Kz5KbEC34bcnfj_UpmPG0YHigxjbdV_zpjabwBWBytj_W7dr4ugL8Q7IaD472bZgZbMsCOXuyhmohBE5nVKhOorv6XNDVWO0eFl1-Zp5gmpAuzntiQaWBUgvDD5B9WUpC0dDdBA3Xhih7kRaG6waWl_qVVkr4mzcFqRmivXDmYVYfLpZnuqVxSh4-9AC7bd9Icrn2fFTCoHzczsJPN8P-16n_BjxnRA72LkIQx7xIWw8qJv_hkPnR/https%3A%2F%2Fdovetail.com%2Fproducts%2Fcozbatch.html

On Fri, May 15, 2020 at 10:12 AM Jack J. Woehr  wrote:

> On 5/15/20 8:51 AM, Seymour J Metz wrote:
> > I understand why they parse pgm and sh differently. What I don't
> understand is why instream data should be treated differently from other
> datasets.
>
> Because it's easier to present to the Unix System Services environment
> that way?
> Unix is stream oriented, not record oriented, and shell syntax is molded
> to that.
> There are shell features like "here documents" (google it) which you've
> probably never used that would get broken if input to the USS shell got
> arbitrarily broken into lines to suit the flavor of MVS/TSO/JES
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> http://secure-web.cisco.com/1gESWY33ldhCr_PLmzxOYS5kRZsH5Jydluqvcg3t9MPdfU6x1ydUzY2STwg49U53joXvW9MqU7qeVG1rzBwhnCuzzvAp06_kN0hg-HOY48DYj5sjsGbyf4Y4o1u16bdiQTQwbPH7w4NZAwoOlQT7Y6gPqz_nehnFJinPk_xF5VqBR8HOH2yWGGOdb81ML09T3VUzHm0dbK1UfatdI1MsMcX0zNOiUAHui4VwiwH2EraXz6ZBdNBjruuZ13Nm8jAFkKRFpphvG5odt_angEbyEh12MMa-9JqD-YHvT_Ro1Y-A4SmvxKszGzOeN8DzrG6ifDRlGLu69L6FrN-LoH1-duTRNa4AlO-4AOOULkrGB2d-1kj5XLBR0npsMO3BZVSDwuP_HZoeoJZcgJ1O4NDZR91cSsyxuctt7pi9czx4a3KNLPnU8eQHIKBg8qFkmLjc0/http%3A%2F%2Fwww.well.com%2F%7Ejax
>  # thinking, a way of skeptically interrogating the
> universe
> http://secure-web.cisco.com/1c3bguWSr6vX_z9MzaC9qKeA90R2_IXvUWNYaxNOPZEwapHRxEeNZIP5t_lyYQlEm00CjAYwR5XIeVuxmpCFmaU1e08LVCXTddtN_aCrhbSIVtjDNsCoPYUdchbDTDgU8G8XiLSeh00_ZsYnxAffHN5MwnqwljzkoFgy1aBBOqhgwEOuwhrhlkK90h37VrmniazBwQ2Cr1FeHaHR5IWL2S04PUKukm7EHWnaAw7ZqMH9LTdB2Sh8_M9xG_JhtvcnezixRxoCQGMY4L2ERQ3-2mcds8hu6-uO2dd5-w0TdjjF8h13FF9wAv92ofsTX2y0yLzqEp6aM6B-fotmfvmRlg2djTqbrDKXl8I3IpEox8BzgNtqQWHQeLLutbcDbLHUp7HkRaMxhDiUQKdJAEvGaKqI7b9lFzHWvwrC6yqm8NzZr4yVYJ50ist5FATq0Vmey/http%3A%2F%2Fwww.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
>

--
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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Kirk Wolf]

Having personally spent a large amount of time dealing with this issue,
what I can tell you is that for non-VSAM data sets that the best that you
can do in most cases (without actually reading the data set) is to look at
the DSCBs  to get the last used TTR and then calculate an estimate of the
data set size based on the recfm and blksize.There are some special
cases, like compressed data sets where the catalog can help.

It would be fantastic if somewhere you could get:
1) the number of logical records
2) the total number of bytes
3) fine grained timestamp when the data set was last updated
4) sha256 hash of the data set

On Thu, May 14, 2020 at 10:55 AM Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> This question came to me from a co-worker: Is there any API to get the
> byte file size of a non-VSAM, non-zFS, non-database file in z/OS?  I.E.,
> byte file size for plain sequential files?
>
> I am aware of the "old way" of reading the VTOC of a volume to get the
> various DSCB's that total up disk extents, but that gets complicated
> quickly for multi-volume files, and was never guaranteed to be accurate as
> to the actual byte count of data in the file except in the RECFM=FS/FBS
> case anyway.
>
> There is always the performance-killing option of just reading the whole
> file and totaling up the length of every record (or block depending on how
> you structure the reads), but no one would call that an API.
>
> As far as I know there is no such API in z/OS, and this is what I told my
> co-worker, but am I wrong?  Is there an alternative of which I am not aware?
>
> TIA for your input.
>
> Peter
> --
>
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: USS: su: User ID "SH" does not exist

[Seymour J Metz]

I thought that you could turn off TSO recognition of semicolon with PROFILE or 
TERMINAL but, no, you can't. I'm not sure what happens if CLIST or REXX code 
passes a semicolon. OTOH, TSO will accept a semicolon in a quoted string.

The TSO command is OMVS and it is documented in z/OS UNIX System Services 
Command Reference.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Friday, May 15, 2020 12:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

On Fri, 15 May 2020 14:02:25 +, Seymour J Metz wrote:

>Semicolon is a separator for TSO SH as well, but you have to keep TSO from 
>recognizing it.
>
Can it be quoted or escaped?  What about on the ISPF command line?

Where is the "TSO SH" command described?  TSO Command Ref?  UNIX Command Ref?
Other (specify)?

-- gil

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

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

Re: USS: su: User ID "SH" does not exist

[Paul Gilmartin]

On Fri, 15 May 2020 11:26:29 -0500, Kirk Wolf wrote:
>
>STDPARM washes away the record boundaries (see the doc).  The semicolons
>
What if you start each line with x'15'?
ISPF Edit change all ';' x'15 1 1'?

>are required at the end of DD:STDPARM records so that this single argument
>to "/bin/sh -c " can  be broken into multiple shell commands.   The whole
>thing is an ugly hack.
> 
>FWIW, I've been using the shell in z/OS batch since 2007 with its stdin
>coming from //STDIN DD *.   And yes, I know what here documents are.   I
>just don't use  brain dead BPXBATCH.
> 
How do you *really* feel about it?

-- gil

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

Re: USS: su: User ID "SH" does not exist

[Kirk Wolf]

Jack,
I would disagree with your explanation of why BPXBATCH works so poorly ;-)

In the OP's example, DD STDPARM is used to construct a single PARM string
that ends up getting passed to BPXBATCH.
What BPXBATCH does is look at the leading "SH"  in it's PARM and then pass
the rest of the string as the argument to "/bin/sh -c"

STDPARM washes away the record boundaries (see the doc).  The semicolons
are required at the end of DD:STDPARM records so that this single argument
to "/bin/sh -c " can  be broken into multiple shell commands.   The whole
thing is an ugly hack.

FWIW, I've been using the shell in z/OS batch since 2007 with its stdin
coming from //STDIN DD *.   And yes, I know what here documents are.   I
just don't use  brain dead BPXBATCH.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com
https://dovetail.com/products/cozbatch.html

On Fri, May 15, 2020 at 10:12 AM Jack J. Woehr  wrote:

> On 5/15/20 8:51 AM, Seymour J Metz wrote:
> > I understand why they parse pgm and sh differently. What I don't
> understand is why instream data should be treated differently from other
> datasets.
>
> Because it's easier to present to the Unix System Services environment
> that way?
> Unix is stream oriented, not record oriented, and shell syntax is molded
> to that.
> There are shell features like "here documents" (google it) which you've
> probably never used that would get broken if input to the USS shell got
> arbitrarily broken into lines to suit the flavor of MVS/TSO/JES
>
> --
> 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
>

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

Does allocating an HFS or zFS erase all existing data?intervals formatted?

[Seymour J Metz]

I want to edit the wiki article [[Disk formatting]] to clarify the statement "s 
a general rule,[nb 1] formatting a disk erases most if not all existing data on 
the disk medium". Normally I would consult the logic manuals :-(

When you allocate an HFS or linear data set, does AMS preformat all of the 
tracks? When you format a zFS, does that force formatting of all tracks? Can 
you provide references that I can cite for the answers?

Thanks.



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

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

Re: USS: su: User ID "SH" does not exist

[Paul Gilmartin]

On Fri, 15 May 2020 14:02:25 +, Seymour J Metz wrote:

>Semicolon is a separator for TSO SH as well, but you have to keep TSO from 
>recognizing it.
>
Can it be quoted or escaped?  What about on the ISPF command line?

Where is the "TSO SH" command described?  TSO Command Ref?  UNIX Command Ref?
Other (specify)?

-- gil

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

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Jackson, Rob]

It's not even close to implausibly huge.  I got so tired of it, I wrote some 
stem-based buffered I/O routines (using both Value() and Interpret, naturally; 
sorry, Gil).

First Horizon Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, May 15, 2020 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

[External Email. Exercise caution when clicking links or opening attachments.]

Right, it appears to be magic -- "just say EXECIO and presto there's the record 
count in STEM.0" -- but under the covers it is reading through the whole 
dataset and counting.

Rexx is all 31-bit, right? So the limit would presumably be something in the 1 
to 2 GB range. That is not an implausibly huge dataset. 1GB is what? 800 
cylinders or somewhat more, depending on blocking, short tracks, etc.?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Bickerdike
Sent: Thursday, May 14, 2020 11:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

> EXECIO in REXX will give you the record count in stem zero

I believe only by reading the entire file.

On Fri, May 15, 2020 at 8:02 AM Charles Mills  wrote:

> > EXECIO in REXX will give you the record count in stem zero
>
> I believe only by reading the entire file.
>
> Charles
>

Agree Charles. It's sort of hidden and would need a large memory allocation for 
the stem.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Charles Mills]

Right, it appears to be magic -- "just say EXECIO and presto there's the record 
count in STEM.0" -- but under the covers it is reading through the whole 
dataset and counting. 

Rexx is all 31-bit, right? So the limit would presumably be something in the 1 
to 2 GB range. That is not an implausibly huge dataset. 1GB is what? 800 
cylinders or somewhat more, depending on blocking, short tracks, etc.?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Bickerdike
Sent: Thursday, May 14, 2020 11:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, 
non-database files?

> EXECIO in REXX will give you the record count in stem zero

I believe only by reading the entire file.

On Fri, May 15, 2020 at 8:02 AM Charles Mills  wrote:

> > EXECIO in REXX will give you the record count in stem zero
>
> I believe only by reading the entire file.
>
> Charles
>

Agree Charles. It's sort of hidden and would need a large memory allocation
for the stem.

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

Re: USS: su: User ID "SH" does not exist

[Paul Gilmartin]

On Fri, 15 May 2020 15:43:34 +, Seymour J Metz wrote:

>I hate that URL mangling! 
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/bpxbatr.htm
> 
And that one didn't get mangled.  It's the Command Ref.

>IBM Knowledge Center
>
> Home -> z/OS 2.1.0 -> z/OS UNIX System Services -> z/OS UNIX System Services 
> User's Guide -> The z/OS shells -> Using z/OS UNIX from batch, TSO/E, and 
> ISPF -> The BPXBATCH utility -> Passing parameter data to BPXBATCH -> 
> Guidelines for defining STDPARM
> 
But that's the User's Guide.  Rules belong in the Ref.

In-stream seems to be the exception that proves the rule, but
what rule applies to non-in-stream?

IBM screwed it up.  And there's no upward-compatible recovery path.
Perhaps an entirely different DDNAME.

>__
>From: Paul Gilmartin
>Sent: Friday, May 15, 2020 11:08 AM
>
>>"For in-stream data sets: with the SH option, trailing blanks are not 
>>truncated. Records in in-stream data sets are concatenated with blanks as 
>>separator characters, and the string remaining after the SH token is passed 
>>as a single argument to a /bin/sh -c command. For the PGM option, the string 
>>is divided not only at line boundaries but also at horizontal white space 
>>within a line. "

-- gil

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

Re: USS: su: User ID "SH" does not exist

[Paul Gilmartin]

On Fri, 15 May 2020 09:12:36 -0600, Jack J. Woehr  wrote:
>
>There are shell features like "here documents" (google it) which you've
>probably never used that would get broken if input to the USS shell got
>arbitrarily broken into lines to suit the flavor of MVS/TSO/JES
>
Au contraire.  Here documents work far better if record boundaries
are preserved (not arbitrarily; converted to NL); hardly at all if lines
are concatenated.

I use them regularly

BPXWUNIX does much better.  Fantasy RFE: provide a rudimentary
wrapper for BPXWUNIX callable via IRXJCL, not much more than:

SIGNAL ON NOVALUE
parse arg Login Cmd  /* Cmd may have multiple tokens.  */
address MVS
'EXECIO * DISKR STDENV (stem ENV.'  /* Error recovery?  */
call BPXWUNIX Cmd, 'DD:STDIN', 'DD:STDOUT', 'DD:STDERR', 'ENV.', Login
return RESULT

I'd expect DD *,SYMBOLS= to work for STDIN.

-- gil

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

Re: USS: su: User ID "SH" does not exist

[Seymour J Metz]

I hate that URL mangling! 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/bpxbatr.htm

IBM Knowledge Center

 Home -> z/OS 2.1.0 -> z/OS UNIX System Services -> z/OS UNIX System Services 
User's Guide -> The z/OS shells -> Using z/OS UNIX from batch, TSO/E, and ISPF 
-> The BPXBATCH utility -> Passing parameter data to BPXBATCH -> Guidelines for 
defining STDPARM



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Friday, May 15, 2020 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

On Fri, 15 May 2020 13:35:59 +, Seymour J Metz wrote:

>"For in-stream data sets: with the SH option, trailing blanks are not 
>truncated. Records in in-stream data sets are concatenated with blanks as 
>separator characters, and the string remaining after the SH token is passed as 
>a single argument to a /bin/sh -c command. For the PGM option, the string is 
>divided not only at line boundaries but also at horizontal white space within 
>a line. "
>
Where did you find that (citation needed)?  I find only roughly
similar for STDPARM in:
z/OS  Version 2 Release 4
UNIX System Services Command Reference
IBM   SA23-2280-40

>Which doesn't make a lot of sense. If it is not taken as a single parameter 
>for other file types, why not?
>
There appears to be a woeful lack of communication among
designers, coders, and tech writers.  Almost more than can be
fixed by RCF.  Examples needed for Cartesian product of:
{SH|PGM} {FB|VB} {PATH|DSN|SYSIN} {single|multiple commands}

-- gil

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

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

Re: USS: su: User ID "SH" d actuallyoes not exist

[Seymour J Metz]

> Because it's easier to present to the Unix System Services environment
> that way?

Maybe in some alternate universe.

> Unix is stream oriented, not record oriented,

Water is wet. How dos that justify treating instream datasets differently from 
other datasets.

> There are shell features like "here documents" (google it)

Your prejudices are showing.

> which you've probably never used 

Don't teach your grandmother to suck eggs.

> that would get broken if input to the USS

ITYM Unix.

> shell got arbitrarily broken into lines to suit the flavor of MVS/TSO/JES

Then why are you defending that behavior? Or did you reply without reading what 
I wrote?


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



From: IBM Mainframe Discussion List  on behalf of 
Jack J. Woehr 
Sent: Friday, May 15, 2020 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

On 5/15/20 8:51 AM, Seymour J Metz wrote:
> I understand why they parse pgm and sh differently. What I don't understand 
> is why instream data should be treated differently from other datasets.

Because it's easier to present to the Unix System Services environment
that way?
Unix is stream oriented, not record oriented, and shell syntax is molded
to that.
There are shell features like "here documents" (google it) which you've
probably never used that would get broken if input to the USS shell got
arbitrarily broken into lines to suit the flavor of MVS/TSO/JES

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
http://secure-web.cisco.com/1uhIumqu4Yytww8FAYDeh9gdDCn3U1XjrWal1i4CefzYYQ6yHkXE0p1dGv3_UdhNktZACVhz65RyFEEifq64ghbny1-q7JnAYbZ_XpWr7xOAKJrCrIBPXq8ojpUZo-c3HxCICo2veAX67mZgXwULoqh9XcnG1m3F0SG5VzJnfbnDRT-A3OAsnbMt3igLX2nz7AuwnBn4pke6_jp9Z-c_CPrbtgsZcCltTBt50wB2hAYIv-mF1S6Sxn3uxMtxJipVzxKDhVopdg7gMO8OTwzPh5-IK-JH3YimgpRvOizHqNZymsd-uueahOCFAunZnNaweuvf0i1XmCsYuqRyNUu_B236wFh7anyxP9XsR_R7ygiIWNQpuavlwwKi-Qkh7qtjDlLLmKLyRLY5Jsa_NlgVPmFxLhC3q-DxXAuqGQi7O9eiwDjULtvjHHtQQev1DJ8Fs0I5KhSczrZxfVK8lswptyg/http%3A%2F%2Fwww.well.com%2F%7Ejax
 # thinking, a way of skeptically interrogating the universe
http://secure-web.cisco.com/1VAxnSGLYbYpB-pnDdw6DGBPH4t4tbuC975NIb6MA6-IAEEkCqn5moB2N0KLWJk0nhRwxswWOwPEdgwF3GWj_pGOQOPSUdG0h6aBstBrgbJrr7GBDTroY6vQuAu4Kzz9hHhEwTv9ox_TLNPWNRORyAzvJpD6WoYy-r4zDs6_mgDTFDThnvhPD6_iali8ar2MykNgrv7XdwfOrtKP0qLV_X3bi0W0JrdoM7q4tXvypcNyGlkBc3pswXtOlFdqDoQRZC7prw86pv0uHmuuKp0K0SKMS1js30AU-KiiixtXK0NUaWMYIAAuwdPzQs0ifYEXRggAU3zHvKVKokPW5KHAkNpI5dWDH5JoLxs4l5Y9yqjAbMGJuAYAV0dgN2uUUyn2g0AycjSSWgOlysmZNYdCT1_XSZXr9sK4f0dLTwOGzGpEtH63U2pICaSfN_iez_kb3/http%3A%2F%2Fwww.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

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

Re: USS: su: User ID "SH" does not exist

[Paul Gilmartin]

On Fri, 15 May 2020 09:30:46 -0500, Joel C. Ewing  wrote:

>I think that maybe they are trying to imply ..l.
> 
Stop! That's not how to document.


On Fri, 15 May 2020 14:51:10 +, Seymour J Metz wrote:
>
>I understand why they parse pgm and sh differently. What I don't understand is 
>why instream data should be treated differently from other datasets. 
>
They believed, erroneously, that instream data can only be fixed-80.
But that doesn't justify treating instream data differently from other
data sets with similar attributes.

-- gil

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

Re: USS: su: User ID "SH" does not exist

[Jack J. Woehr]

On 5/15/20 8:51 AM, Seymour J Metz wrote:

I understand why they parse pgm and sh differently. What I don't understand is 
why instream data should be treated differently from other datasets.


Because it's easier to present to the Unix System Services environment 
that way?
Unix is stream oriented, not record oriented, and shell syntax is molded 
to that.
There are shell features like "here documents" (google it) which you've 
probably never used that would get broken if input to the USS shell got 
arbitrarily broken into lines to suit the flavor of MVS/TSO/JES


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

Re: USS: su: User ID "SH" does not exist

[Paul Gilmartin]

On Fri, 15 May 2020 13:35:59 +, Seymour J Metz wrote:

>"For in-stream data sets: with the SH option, trailing blanks are not 
>truncated. Records in in-stream data sets are concatenated with blanks as 
>separator characters, and the string remaining after the SH token is passed as 
>a single argument to a /bin/sh -c command. For the PGM option, the string is 
>divided not only at line boundaries but also at horizontal white space within 
>a line. "
>
Where did you find that (citation needed)?  I find only roughly
similar for STDPARM in:
z/OS  Version 2 Release 4
UNIX System Services Command Reference
IBM   SA23-2280-40
 
>Which doesn't make a lot of sense. If it is not taken as a single parameter 
>for other file types, why not?
>
There appears to be a woeful lack of communication among
designers, coders, and tech writers.  Almost more than can be
fixed by RCF.  Examples needed for Cartesian product of:
{SH|PGM} {FB|VB} {PATH|DSN|SYSIN} {single|multiple commands}

-- gil

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

z/Aware

[Steve Beaver]

I just got z/Aware dumped into my LAP to install and configure

 

Does anyone have any experience with z/Aware?

 

 

 


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

Re: USS: su: User ID "SH" does not exist

[Seymour J Metz]

I understand why they parse pgm and sh differently. What I don't understand is 
why instream data should be treated differently from other datasets. 


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



From: IBM Mainframe Discussion List  on behalf of 
Joel C. Ewing 
Sent: Friday, May 15, 2020 10:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

I think that maybe they are trying to imply that if "PGM" is used, the
whole rest of the multi-line string is parsed as MVS-style program
parameters, with record  boundaries always being a parameter boundary,
and passed to the program. if "SH" is used, the entire string is passed
as the "command" argument to the unix shell, which then parses it as
unix commands plus parameters according to unix command syntax rules; so
that with only a blank at end-of-record, an in-stream end-of-line might
not be the end of a command or even the end of a parameter.   Either
way, highly confusing as would appear to be a  collision of two
paradigms.  Multiple examples of what they really meant would have been
useful.
Joel C Ewing

On 5/15/20 8:35 AM, Seymour J Metz wrote:
> "For in-stream data sets: with the SH option, trailing blanks are not 
> truncated. Records in in-stream data sets are concatenated with blanks as 
> separator characters, and the string remaining after the SH token is passed 
> as a single argument to a /bin/sh -c command. For the PGM option, the string 
> is divided not only at line boundaries but also at horizontal white space 
> within a line. "
>
> Which doesn't make a lot of sense. If it is not taken as a single parameter 
> for other file types, why not?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Jon Bathmaker [jon.bathma...@sys1consulting.com]
> Sent: Friday, May 15, 2020 8:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: USS: su: User ID "SH" does not exist
>
> Hi Ed,
>
> Thanks for this!  How *did* you find out about the semicolons, I didn't
> see them anywhere in the doc.
>
> Best regards,
> *Jon Bathmaker,*
> SYS1 Consulting Inc.
> 519-577-9661
>
>
>
> On 5/15/2020 12:19 AM, Ed Jaffe wrote:
>> On 5/14/2020 5:23 PM, Jon Bathmaker wrote:
>>> //STDPARM DD *
>>> SH su
>>> SH echo $PATH
>>> SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
>>
>> The above looks wrong to me. I always do it this way:
>>
>>
>> //STDPARM  DD *
>> SH su;
>>echo $PATH;
>>unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
>>
>>
> ...


--
Joel C. Ewing

--
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: USS: su: User ID "SH" does not exist

[Joel C. Ewing]

I think that maybe they are trying to imply that if "PGM" is used, the
whole rest of the multi-line string is parsed as MVS-style program
parameters, with record  boundaries always being a parameter boundary,
and passed to the program. if "SH" is used, the entire string is passed
as the "command" argument to the unix shell, which then parses it as
unix commands plus parameters according to unix command syntax rules; so
that with only a blank at end-of-record, an in-stream end-of-line might
not be the end of a command or even the end of a parameter.   Either
way, highly confusing as would appear to be a  collision of two
paradigms.  Multiple examples of what they really meant would have been
useful.
    Joel C Ewing

On 5/15/20 8:35 AM, Seymour J Metz wrote:
> "For in-stream data sets: with the SH option, trailing blanks are not 
> truncated. Records in in-stream data sets are concatenated with blanks as 
> separator characters, and the string remaining after the SH token is passed 
> as a single argument to a /bin/sh -c command. For the PGM option, the string 
> is divided not only at line boundaries but also at horizontal white space 
> within a line. "
>
> Which doesn't make a lot of sense. If it is not taken as a single parameter 
> for other file types, why not?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Jon Bathmaker [jon.bathma...@sys1consulting.com]
> Sent: Friday, May 15, 2020 8:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: USS: su: User ID "SH" does not exist
>
> Hi Ed,
>
> Thanks for this!  How *did* you find out about the semicolons, I didn't
> see them anywhere in the doc.
>
> Best regards,
> *Jon Bathmaker,*
> SYS1 Consulting Inc.
> 519-577-9661
>
>
>
> On 5/15/2020 12:19 AM, Ed Jaffe wrote:
>> On 5/14/2020 5:23 PM, Jon Bathmaker wrote:
>>> //STDPARM DD *
>>> SH su
>>> SH echo $PATH
>>> SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
>>
>> The above looks wrong to me. I always do it this way:
>>
>>
>> //STDPARM  DD *
>> SH su;
>>echo $PATH;
>>unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
>>
>>
> ...


-- 
Joel C. Ewing

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

Re: USS: su: User ID "SH" does not exist

[Don Poitras]

Jon,
  You have to email the listserv for everyone to see your note. See
instructions at the bottom of this post. 

All,
  I think I've posted this before, but this is how I avoid semi-colons and
plus signs. I just have a job where I can type normal commands and see the
output as I'd like. 

//DONBPX JOB (,R282),POITRAS,NOTIFY=SASDTP,TIME=(0,10),CLASS=A,
//REGION=1M,MSGCLASS=A  
//* 
//*  The idea here is that I'd like to see the commands printed 
//*  along with the output. set -x will do that (while printing 
//*  a "++" in front of the commands, but that's ok), but sends  
//*  it's debugging output to stderr. By setting stdout and 
//*  stderr to the same file, the output is interleaved and the 
//*  final step prints the result.  
//* 
//COPY1EXEC PGM=IEBGENER
//SYSINDD DUMMY 
//SYSUT1   DD * 
set -x  
cd /u/sasdtp/temp   
pwd 
ls -Fartl   
date
/*  
//SYSUT2   DD PATH='/u/sasdtp/donbpx2.txt', 
//PATHOPTS=(ORDWR,OTRUNC,OCREAT),PATHMODE=SIRWXU,   
//PATHDISP=(KEEP,DELETE),FILEDATA=TEXT  
//SYSPRINT DD SYSOUT=*  
//BPXBAT   EXEC PGM=BPXBATCH,PARMDD=PARMINDD
//STDINDD DUMMY 
//STDOUT   DD PATH='/u/sasdtp/donbpx2.out.txt', 
//PATHOPTS=(OWRONLY,OTRUNC,OCREAT),PATHMODE=SIRWXU, 
//PATHDISP=(KEEP,DELETE),FILEDATA=TEXT  
//STDERR   DD PATH='/u/sasdtp/donbpx2.out.txt', 
//PATHOPTS=(OWRONLY,OTRUNC,OCREAT),PATHMODE=SIRWXU, 
//PATHDISP=(KEEP,DELETE),FILEDATA=TEXT  
//PARMINDD DD * 
sh /u/sasdtp/donbpx2.txt
/*  
//COPY2EXEC PGM=IEBGENER
//SYSINDD DUMMY 
//SYSUT1   DD PATH='/u/sasdtp/donbpx2.out.txt', 
//PATHOPTS=(ORDONLY),   
//RECFM=VB,LRECL=1024,BLKSIZE=3000  
//SYSUT2   DD SYSOUT=*  
//SYSPRINT DD SYSOUT=*  
//  

result:

++ cd /u/sasdtp/temp   
++ pwd 
/u/sasdtp/temp 
++ ls -Fartl   
total 620  
-rw-r--r--1 SASDTP   CCD 5797 Jan 20  2011 hexdump.C   
-rwxr-xr-x1 SASDTP   CCD   118784 Jan 20  2011 hexdump*
-rwx--1 SASDTP   CCD   129024 Jan 20  2011 hexdump.pax*
drwxr-xr-x2 SASDTP   CCD 8192 Oct 30  2019 ./  
drwxr-xr-x  131 SASDTP   CCD32768 May 15 14:04 ../ 
++ date
Fri May 15 14:15:35 UTC 2020   


In article <3a46c5b9-6e54-4a14-affb-79dc3437c...@googlegroups.com> you wrote:
> On Friday, May 15, 2020 at 10:23:30 AM UTC+10, Jon Bathmaker wrote:
> > Hi,
> > 
> > Because of auditor demands we are no longer able to run TSO USS commands 
> > that require UID=0,?? so I attempting figure out how to run?? USS commands 
> > in under BPXBATCH.?? The following is a job to debug the unmount command 
> > in batch but I have been unsuccessful so far. I am hoping that I am 
> > doing something wrong and that one of you can point out my error.
> > 
> > Here is the JCL:
> > 
> > //BATBPX?? EXEC PGM=BPXBATCH
> > 
> > //STEPLIB?? DD DISP=SHR,DSN=SYS1.CEE.SCEERUN
> > 
> > //STDERR DD SYSOUT=*
> > 
> > //STDOUT?? ??DD SYSOUT=*
> > 
> > //STDPARM?? DD *
> > 
> > SH su
> > 
> > SH echo $PATH
> > 
> > SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
> > 
> > Here is the contents of STDERR when the job runs.
> > 
> > FSUM5023 su: User ID "SH" does not exist, or the 

Re: USS: su: User ID "SH" does not exist

[Seymour J Metz]

Semicolon is a separator for TSO SH as well, but you have to keep TSO from 
recognizing it.


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



From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Friday, May 15, 2020 9:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

I'm talking about the TSO SH command not a shell script!

On 2020-05-15 9:13 PM, Joel C. Ewing wrote:
> Nope.   In Unix, semicolons are command separators, not a continuation
> indicator.  The actual command continuation character is "\", but that
> is only needed just prior to an EOL character.
>
> It would appear that in this environment no end-of-line characters are
> seen, so unix just sees "SH su  SH ...".  Without the
> semicolon the shell sees the command  "su SH", which is an attempt to
> switch to the context of user "SH".   In the absence of a recognized
> EOL/ENTER to indicate end of command, the semicolon must be used between
> commands -- although putting an extra one at the end doesn't hurt -- it
> just sees a null command at the end.
>
> This requirement may not be documented.   They may just assume that
> everyone familiar with Unix will of course "know" this if they describe
> the STDPARM file as being treated as a single string  or a single line
> with no EOL forced at the end of each record.
>  Joel C Ewing
>
>
> On 5/15/20 7:47 AM, David Crayford wrote:
>> Nope. Semicolons are a continuation!
>>
>> On 2020-05-15 8:13 PM, David Spiegel wrote:
>>> Hi Jon,
>>> Every line except for the last line needs a semicolon.
>>>
>>> Regards,
>>> David
>>>
>>> On 2020-05-15 08:10, Jon Bathmaker wrote:
 Hi Ed,

 Thanks for this!  How *did* you find out about the semicolons, I
 didn't see them anywhere in the doc.

 Best regards,
 *Jon Bathmaker,*
 SYS1 Consulting Inc.
 519-577-9661



 On 5/15/2020 12:19 AM, Ed Jaffe wrote:
> On 5/14/2020 5:23 PM, Jon Bathmaker wrote:
>> //STDPARM DD *
>> SH su
>> SH echo $PATH
>> SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
>
> The above looks wrong to me. I always do it this way:
>
>
> //STDPARM  DD *
> SH su;
> echo $PATH;
> unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
>
>
 ..
>

--
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: USS: su: User ID "SH" does not exist

[David Crayford]

I'm talking about the TSO SH command not a shell script!

On 2020-05-15 9:13 PM, Joel C. Ewing wrote:

Nope.   In Unix, semicolons are command separators, not a continuation
indicator.  The actual command continuation character is "\", but that
is only needed just prior to an EOL character.

It would appear that in this environment no end-of-line characters are
seen, so unix just sees "SH su  SH ...".  Without the
semicolon the shell sees the command  "su SH", which is an attempt to
switch to the context of user "SH".   In the absence of a recognized
EOL/ENTER to indicate end of command, the semicolon must be used between
commands -- although putting an extra one at the end doesn't hurt -- it
just sees a null command at the end.

This requirement may not be documented.   They may just assume that
everyone familiar with Unix will of course "know" this if they describe
the STDPARM file as being treated as a single string  or a single line
with no EOL forced at the end of each record.
     Joel C Ewing


On 5/15/20 7:47 AM, David Crayford wrote:

Nope. Semicolons are a continuation!

On 2020-05-15 8:13 PM, David Spiegel wrote:

Hi Jon,
Every line except for the last line needs a semicolon.

Regards,
David

On 2020-05-15 08:10, Jon Bathmaker wrote:

Hi Ed,

Thanks for this!  How *did* you find out about the semicolons, I
didn't see them anywhere in the doc.

Best regards,
*Jon Bathmaker,*
SYS1 Consulting Inc.
519-577-9661



On 5/15/2020 12:19 AM, Ed Jaffe wrote:

On 5/14/2020 5:23 PM, Jon Bathmaker wrote:

//STDPARM DD *
SH su
SH echo $PATH
SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS


The above looks wrong to me. I always do it this way:


//STDPARM  DD *
SH su;
    echo $PATH;
    unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS



..




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

Re: USS: su: User ID "SH" does not exist

[Seymour J Metz]

Of course: semicolon is the standard *ix command separator. If the parameter 
following -c includes a semicol then it is treated as multiple commands.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Spiegel [dspiegel...@hotmail.com]
Sent: Friday, May 15, 2020 9:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

Hi R'Shmuel,
BPXBATCH allows only one Command Buffer. If the user wants to issue more
than one command, then s/he must separate commands with a semicolon
(much like the ISPF Command line).

Regards,
David

On 2020-05-15 09:32, Seymour J Metz wrote:
> Possibly, but ; is definitely a command separator character, not a 
> continuation character.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://eur05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Ca1d14b2155ab4d26d96808d7f8d47ff5%7C84df9e7fe9f640afb435%7C1%7C0%7C637251463900660906sdata=0v7lCqOekIfyjsPxgu%2BQw9Rp%2FwNpXSERP%2F8lo5%2F04Tg%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> David Crayford [dcrayf...@gmail.com]
> Sent: Friday, May 15, 2020 9:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: USS: su: User ID "SH" does not exist
>
> Yes, in a shell, but no using BPXBATCH.
>
> On 2020-05-15 9:17 PM, Seymour J Metz wrote:
>> ITYM \ at the end is a continuation.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> https://eur05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Ca1d14b2155ab4d26d96808d7f8d47ff5%7C84df9e7fe9f640afb435%7C1%7C0%7C637251463900660906sdata=0v7lCqOekIfyjsPxgu%2BQw9Rp%2FwNpXSERP%2F8lo5%2F04Tg%3Dreserved=0
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>> David Crayford [dcrayf...@gmail.com]
>> Sent: Friday, May 15, 2020 8:47 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: USS: su: User ID "SH" does not exist
>>
>> Nope. Semicolons are a continuation!
>>
>> On 2020-05-15 8:13 PM, David Spiegel wrote:
>>> Hi Jon,
>>> Every line except for the last line needs a semicolon.
>>>
>>> Regards,
>>> David
>>>
>>> On 2020-05-15 08:10, Jon Bathmaker wrote:
 Hi Ed,

 Thanks for this!  How *did* you find out about the semicolons, I
 didn't see them anywhere in the doc.

 Best regards,
 *Jon Bathmaker,*
 SYS1 Consulting Inc.
 519-577-9661



 On 5/15/2020 12:19 AM, Ed Jaffe wrote:
> On 5/14/2020 5:23 PM, Jon Bathmaker wrote:
>> //STDPARM DD *
>> SH su
>> SH echo $PATH
>> SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
> The above looks wrong to me. I always do it this way:
>
>
> //STDPARM  DD *
> SH su;
>  echo $PATH;
>  unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
>
>
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 .
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .

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

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

Re: BPXBATCH cannot find su command

[Seymour J Metz]

"This is because SH causes BPXBATCH to execute a login shell that runs the 
/etc/profile script and runs the user's .profile."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Bathmaker [jon.bathma...@sys1consulting.com]
Sent: Friday, May 15, 2020 9:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BPXBATCH cannot find su command

Morning ladies and gents,

Running a BPXBATCH job, with the following STDPARM:

SH su

I get the following STDERR:

/bin:/usr/lpp/java/J1.4_64/bin/:/u/#T95JXB/scripts: FSUM7351 not found

I have corrected the path in /etc/profile and it is correct in the shell
but BPXBATCH does not pick it up.   Do I need to recycle USS before
BPXBATCH will see it?   Thanks.

Best regards,

Jon Bathmaker

SYS1 Consulting Inc.

519-577-9661


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

BPXBATCH cannot find su command

[Jon Bathmaker]

Morning ladies and gents,

Running a BPXBATCH job, with the following STDPARM:

SH su

I get the following STDERR:

/bin:/usr/lpp/java/J1.4_64/bin/:/u/#T95JXB/scripts: FSUM7351 not found

I have corrected the path in /etc/profile and it is correct in the shell 
but BPXBATCH does not pick it up.   Do I need to recycle USS before 
BPXBATCH will see it?   Thanks.


Best regards,

Jon Bathmaker

SYS1 Consulting Inc.

519-577-9661


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

Re: USS: su: User ID "SH" does not exist

[David Spiegel]

Hi R'Shmuel,
BPXBATCH allows only one Command Buffer. If the user wants to issue more 
than one command, then s/he must separate commands with a semicolon 
(much like the ISPF Command line).


Regards,
David

On 2020-05-15 09:32, Seymour J Metz wrote:

Possibly, but ; is definitely a command separator character, not a continuation 
character.


--
Shmuel (Seymour J.) Metz
https://eur05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Ca1d14b2155ab4d26d96808d7f8d47ff5%7C84df9e7fe9f640afb435%7C1%7C0%7C637251463900660906sdata=0v7lCqOekIfyjsPxgu%2BQw9Rp%2FwNpXSERP%2F8lo5%2F04Tg%3Dreserved=0


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Friday, May 15, 2020 9:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

Yes, in a shell, but no using BPXBATCH.

On 2020-05-15 9:17 PM, Seymour J Metz wrote:

ITYM \ at the end is a continuation.


--
Shmuel (Seymour J.) Metz
https://eur05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Ca1d14b2155ab4d26d96808d7f8d47ff5%7C84df9e7fe9f640afb435%7C1%7C0%7C637251463900660906sdata=0v7lCqOekIfyjsPxgu%2BQw9Rp%2FwNpXSERP%2F8lo5%2F04Tg%3Dreserved=0


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Friday, May 15, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

Nope. Semicolons are a continuation!

On 2020-05-15 8:13 PM, David Spiegel wrote:

Hi Jon,
Every line except for the last line needs a semicolon.

Regards,
David

On 2020-05-15 08:10, Jon Bathmaker wrote:

Hi Ed,

Thanks for this!  How *did* you find out about the semicolons, I
didn't see them anywhere in the doc.

Best regards,
*Jon Bathmaker,*
SYS1 Consulting Inc.
519-577-9661



On 5/15/2020 12:19 AM, Ed Jaffe wrote:

On 5/14/2020 5:23 PM, Jon Bathmaker wrote:

//STDPARM DD *
SH su
SH echo $PATH
SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS

The above looks wrong to me. I always do it this way:


//STDPARM  DD *
SH su;
 echo $PATH;
 unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS



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

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

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

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

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

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


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

Re: USS: su: User ID "SH" does not exist

[Seymour J Metz]

"For in-stream data sets: with the SH option, trailing blanks are not 
truncated. Records in in-stream data sets are concatenated with blanks as 
separator characters, and the string remaining after the SH token is passed as 
a single argument to a /bin/sh -c command. For the PGM option, the string is 
divided not only at line boundaries but also at horizontal white space within a 
line. "

Which doesn't make a lot of sense. If it is not taken as a single parameter for 
other file types, why not?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Bathmaker [jon.bathma...@sys1consulting.com]
Sent: Friday, May 15, 2020 8:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

Hi Ed,

Thanks for this!  How *did* you find out about the semicolons, I didn't
see them anywhere in the doc.

Best regards,
*Jon Bathmaker,*
SYS1 Consulting Inc.
519-577-9661



On 5/15/2020 12:19 AM, Ed Jaffe wrote:
> On 5/14/2020 5:23 PM, Jon Bathmaker wrote:
>> //STDPARM DD *
>> SH su
>> SH echo $PATH
>> SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
>
>
> The above looks wrong to me. I always do it this way:
>
>
> //STDPARM  DD *
> SH su;
>echo $PATH;
>unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
>
>

--
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: USS: su: User ID "SH" does not exist

[Seymour J Metz]

Possibly, but ; is definitely a command separator character, not a continuation 
character.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Friday, May 15, 2020 9:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

Yes, in a shell, but no using BPXBATCH.

On 2020-05-15 9:17 PM, Seymour J Metz wrote:
> ITYM \ at the end is a continuation.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> David Crayford [dcrayf...@gmail.com]
> Sent: Friday, May 15, 2020 8:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: USS: su: User ID "SH" does not exist
>
> Nope. Semicolons are a continuation!
>
> On 2020-05-15 8:13 PM, David Spiegel wrote:
>> Hi Jon,
>> Every line except for the last line needs a semicolon.
>>
>> Regards,
>> David
>>
>> On 2020-05-15 08:10, Jon Bathmaker wrote:
>>> Hi Ed,
>>>
>>> Thanks for this!  How *did* you find out about the semicolons, I
>>> didn't see them anywhere in the doc.
>>>
>>> Best regards,
>>> *Jon Bathmaker,*
>>> SYS1 Consulting Inc.
>>> 519-577-9661
>>>
>>>
>>>
>>> On 5/15/2020 12:19 AM, Ed Jaffe wrote:
 On 5/14/2020 5:23 PM, Jon Bathmaker wrote:
> //STDPARM DD *
> SH su
> SH echo $PATH
> SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS

 The above looks wrong to me. I always do it this way:


 //STDPARM  DD *
 SH su;
 echo $PATH;
 unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS


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

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

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

Re: USS: su: User ID "SH" does not exist

[Seymour J Metz]

Now this is precious: "For in-stream data sets: with the SH option, trailing 
blanks are not truncated. Records in in-stream data sets are concatenated with 
blanks as separator characters, and the string remaining after the SH token is 
passed as a single argument to a /bin/sh -c command. For the PGM option, the 
string is divided not only at line boundaries but also at horizontal white 
space within a line. "

Where is it documented how STDPARM is treated for other datasets and Unix 
files? If the data after the leading shell are not treated as a single 
parameter, why not?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Joel C. Ewing [jcew...@acm.org]
Sent: Friday, May 15, 2020 9:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

Nope.   In Unix, semicolons are command separators, not a continuation
indicator.  The actual command continuation character is "\", but that
is only needed just prior to an EOL character.

It would appear that in this environment no end-of-line characters are
seen, so unix just sees "SH su  SH ...".  Without the
semicolon the shell sees the command  "su SH", which is an attempt to
switch to the context of user "SH".   In the absence of a recognized
EOL/ENTER to indicate end of command, the semicolon must be used between
commands -- although putting an extra one at the end doesn't hurt -- it
just sees a null command at the end.

This requirement may not be documented.   They may just assume that
everyone familiar with Unix will of course "know" this if they describe
the STDPARM file as being treated as a single string  or a single line
with no EOL forced at the end of each record.
Joel C Ewing


On 5/15/20 7:47 AM, David Crayford wrote:
> Nope. Semicolons are a continuation!
>
> On 2020-05-15 8:13 PM, David Spiegel wrote:
>> Hi Jon,
>> Every line except for the last line needs a semicolon.
>>
>> Regards,
>> David
>>
>> On 2020-05-15 08:10, Jon Bathmaker wrote:
>>> Hi Ed,
>>>
>>> Thanks for this!  How *did* you find out about the semicolons, I
>>> didn't see them anywhere in the doc.
>>>
>>> Best regards,
>>> *Jon Bathmaker,*
>>> SYS1 Consulting Inc.
>>> 519-577-9661
>>>
>>>
>>>
>>> On 5/15/2020 12:19 AM, Ed Jaffe wrote:
 On 5/14/2020 5:23 PM, Jon Bathmaker wrote:
> //STDPARM DD *
> SH su
> SH echo $PATH
> SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS


 The above looks wrong to me. I always do it this way:


 //STDPARM  DD *
 SH su;
echo $PATH;
unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS


>>> ..


--
Joel C. Ewing

--
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: USS: su: User ID "SH" does not exist

[David Spiegel]

Hi David,
Yes, I am aware of that. That is *why* they are necessary.
What is your point?

Regards,
David

On 2020-05-15 08:47, David Crayford wrote:

Nope. Semicolons are a continuation!

On 2020-05-15 8:13 PM, David Spiegel wrote:

Hi Jon,
Every line except for the last line needs a semicolon.

Regards,
David

On 2020-05-15 08:10, Jon Bathmaker wrote:

Hi Ed,

Thanks for this!  How *did* you find out about the semicolons, I 
didn't see them anywhere in the doc.


Best regards,
*Jon Bathmaker,*
SYS1 Consulting Inc.
519-577-9661



On 5/15/2020 12:19 AM, Ed Jaffe wrote:

On 5/14/2020 5:23 PM, Jon Bathmaker wrote:

//STDPARM DD *
SH su
SH echo $PATH
SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS



The above looks wrong to me. I always do it this way:


//STDPARM  DD *
SH su;
   echo $PATH;
   unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS




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


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


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


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

Re: USS: su: User ID "SH" does not exist

[David Crayford]

Yes, in a shell, but no using BPXBATCH.

On 2020-05-15 9:17 PM, Seymour J Metz wrote:

ITYM \ at the end is a continuation.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Friday, May 15, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

Nope. Semicolons are a continuation!

On 2020-05-15 8:13 PM, David Spiegel wrote:

Hi Jon,
Every line except for the last line needs a semicolon.

Regards,
David

On 2020-05-15 08:10, Jon Bathmaker wrote:

Hi Ed,

Thanks for this!  How *did* you find out about the semicolons, I
didn't see them anywhere in the doc.

Best regards,
*Jon Bathmaker,*
SYS1 Consulting Inc.
519-577-9661



On 5/15/2020 12:19 AM, Ed Jaffe wrote:

On 5/14/2020 5:23 PM, Jon Bathmaker wrote:

//STDPARM DD *
SH su
SH echo $PATH
SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS


The above looks wrong to me. I always do it this way:


//STDPARM  DD *
SH su;
echo $PATH;
unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS



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

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

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

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


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

Re: USS: su: User ID "SH" does not exist

[Seymour J Metz]

ITYM \ at the end is a continuation.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Friday, May 15, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS: su: User ID "SH" does not exist

Nope. Semicolons are a continuation!

On 2020-05-15 8:13 PM, David Spiegel wrote:
> Hi Jon,
> Every line except for the last line needs a semicolon.
>
> Regards,
> David
>
> On 2020-05-15 08:10, Jon Bathmaker wrote:
>> Hi Ed,
>>
>> Thanks for this!  How *did* you find out about the semicolons, I
>> didn't see them anywhere in the doc.
>>
>> Best regards,
>> *Jon Bathmaker,*
>> SYS1 Consulting Inc.
>> 519-577-9661
>>
>>
>>
>> On 5/15/2020 12:19 AM, Ed Jaffe wrote:
>>> On 5/14/2020 5:23 PM, Jon Bathmaker wrote:
 //STDPARM DD *
 SH su
 SH echo $PATH
 SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
>>>
>>>
>>> The above looks wrong to me. I always do it this way:
>>>
>>>
>>> //STDPARM  DD *
>>> SH su;
>>>echo $PATH;
>>>unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS
>>>
>>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> .
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: USS: su: User ID "SH" does not exist

[Joel C. Ewing]

Nope.   In Unix, semicolons are command separators, not a continuation
indicator.  The actual command continuation character is "\", but that
is only needed just prior to an EOL character.

It would appear that in this environment no end-of-line characters are
seen, so unix just sees "SH su  SH ...".  Without the
semicolon the shell sees the command  "su SH", which is an attempt to
switch to the context of user "SH".   In the absence of a recognized 
EOL/ENTER to indicate end of command, the semicolon must be used between
commands -- although putting an extra one at the end doesn't hurt -- it
just sees a null command at the end.

This requirement may not be documented.   They may just assume that
everyone familiar with Unix will of course "know" this if they describe
the STDPARM file as being treated as a single string  or a single line
with no EOL forced at the end of each record.
    Joel C Ewing


On 5/15/20 7:47 AM, David Crayford wrote:
> Nope. Semicolons are a continuation!
>
> On 2020-05-15 8:13 PM, David Spiegel wrote:
>> Hi Jon,
>> Every line except for the last line needs a semicolon.
>>
>> Regards,
>> David
>>
>> On 2020-05-15 08:10, Jon Bathmaker wrote:
>>> Hi Ed,
>>>
>>> Thanks for this!  How *did* you find out about the semicolons, I
>>> didn't see them anywhere in the doc.
>>>
>>> Best regards,
>>> *Jon Bathmaker,*
>>> SYS1 Consulting Inc.
>>> 519-577-9661
>>>
>>>
>>>
>>> On 5/15/2020 12:19 AM, Ed Jaffe wrote:
 On 5/14/2020 5:23 PM, Jon Bathmaker wrote:
> //STDPARM DD *
> SH su
> SH echo $PATH
> SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS


 The above looks wrong to me. I always do it this way:


 //STDPARM  DD *
 SH su;
    echo $PATH;
    unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS


>>> ..


-- 
Joel C. Ewing

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

Re: USS: su: User ID "SH" does not exist

[Allan Staller]

Use BPXBATSL, Check the fine manuals for details.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Bathmaker
Sent: Thursday, May 14, 2020 7:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: USS: su: User ID "SH" does not exist

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi,

Because of auditor demands we are no longer able to run TSO USS commands that 
require UID=0,  so I attempting figure out how to run  USS commands in under 
BPXBATCH.  The following is a job to debug the unmount command
in batch but I have been unsuccessful so far.   I am hoping that I am
doing something wrong and that one of you can point out my error.

Here is the JCL:

//BATBPX  EXEC PGM=BPXBATCH

//STEPLIB  DD DISP=SHR,DSN=SYS1.CEE.SCEERUN

//STDERR   DD SYSOUT=*

//STDOUT   DD SYSOUT=*

//STDPARM  DD *

SH su

SH echo $PATH

SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS

Here is the contents of STDERR when the job runs.

FSUM5023 su: User ID "SH" does not exist, or the RACF profile does not contain 
an OMVS segment.


Thanks.

Best regards,

Jon Bathmaker

z/OS Systems Programmer


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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: USS: su: User ID "SH" does not exist

[David Crayford]

Nope. Semicolons are a continuation!

On 2020-05-15 8:13 PM, David Spiegel wrote:

Hi Jon,
Every line except for the last line needs a semicolon.

Regards,
David

On 2020-05-15 08:10, Jon Bathmaker wrote:

Hi Ed,

Thanks for this!  How *did* you find out about the semicolons, I 
didn't see them anywhere in the doc.


Best regards,
*Jon Bathmaker,*
SYS1 Consulting Inc.
519-577-9661



On 5/15/2020 12:19 AM, Ed Jaffe wrote:

On 5/14/2020 5:23 PM, Jon Bathmaker wrote:

//STDPARM DD *
SH su
SH echo $PATH
SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS



The above looks wrong to me. I always do it this way:


//STDPARM  DD *
SH su;
   echo $PATH;
   unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS




--
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: USS: su: User ID "SH" does not exist

[David Spiegel]

Hi Jon,
Every line except for the last line needs a semicolon.

Regards,
David

On 2020-05-15 08:10, Jon Bathmaker wrote:

Hi Ed,

Thanks for this!  How *did* you find out about the semicolons, I 
didn't see them anywhere in the doc.


Best regards,
*Jon Bathmaker,*
SYS1 Consulting Inc.
519-577-9661



On 5/15/2020 12:19 AM, Ed Jaffe wrote:

On 5/14/2020 5:23 PM, Jon Bathmaker wrote:

//STDPARM DD *
SH su
SH echo $PATH
SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS



The above looks wrong to me. I always do it this way:


//STDPARM  DD *
SH su;
   echo $PATH;
   unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS




--
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: USS: su: User ID "SH" does not exist

[Jon Bathmaker]

Hi Ed,

Thanks for this!  How *did* you find out about the semicolons, I didn't 
see them anywhere in the doc.


Best regards,
*Jon Bathmaker,*
SYS1 Consulting Inc.
519-577-9661



On 5/15/2020 12:19 AM, Ed Jaffe wrote:

On 5/14/2020 5:23 PM, Jon Bathmaker wrote:

//STDPARM DD *
SH su
SH echo $PATH
SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS



The above looks wrong to me. I always do it this way:


//STDPARM  DD *
SH su;
   echo $PATH;
   unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS




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

Re: 3270 terminals: CUT vs. DFT

[Alexander Huemer]

Hi

> Let me see what I can dig up from the old dusty storage area 

Did you find anything?

-Alex
On Mon, May 11, 2020 at 02:44:21PM -0400, Ken Bloom wrote:
> Hi Alex
> 
> I’m familiar with SNA DFT and in a previous life released several products 
> that utilized it.  I’ll look back at some old docs I have to see if there is 
> anything worth while sending you.   As I said we did 2 products.  One was 
> called the “Port-Xpander” and basically looked like a DFT Terminal on one 
> side (coax attached to a 31 or 3274) and had five coax outputs that connected 
> to 3270 cut terminals.  It was used to expand the port capacity of a 3174 
> from 32 ports up to 160 ports.  The second product was called “SyncLink” and 
> it coax attached to a 3174 mux port and looked like 8 DFT devices on the 
> input side.  The output side was multiple SDLC lines that connected to down 
> stream PU2 devices.   It was in effect a poor mans 3745. Did not require NCP 
> but to remote PU2 devices it looked like a 3745.  
> 
> Let me see what I can dig up from the old dusty storage area 
> 
> Ken
> 
> Kenneth A. Bloom
> CEO
> Avenir Technologies Inc
> /d/b/a Visara International
> 203-984-2235
> bl...@visara.com
> www.visara.com
> 
> 
> > On May 11, 2020, at 2:17 PM, Alexander Huemer  
> > wrote:
> > 
> > Hi
> > 
> > I have a 3290 terminal that I'd like to put to some use. See email 
> > thread 'Talking to 3270 terminals?' that I started Jan 14.
> > Somebody then pointed me to oec[1], which is an awesome project. I have 
> > built the hardware interface that is required to talk to a 3270 terminal 
> > on the hardware level. A picture of the interface and a video of the 
> > terminal can be found at [2].
> > 
> > Now, the friendly person who created oec says that the 3290 is a so 
> > called DFT (Distributed Function Terminal), in contrast to a CUT 
> > (Control Unit Terminal). Most 3270 terminals seem to be of the (simpler) 
> > CUT variant. oec only works with CUT terminals. Extending the 
> > functionality to enable it to work with DFT terminals isn't trivial.
> > 
> > Does anybody on the list here know of additional documentation besides 
> > what's mentioned at [3] that could be helpful to implement DFT support?
> > 
> > What would also be very helpful is a protocol trace of any kind of the 
> > communication between a 3174 and a DFT terminal.
> > 
> > -Alex
> > 
> > [1] https://github.com/lowobservable/oec
> > [2] https://ahuemer.xx.vu/volatile/2020-05-11-P6C1Wc3u1wU/
> > [3] https://github.com/lowobservable/coax/blob/protocol/protocol/protocol.md
> > 
> > --
> > 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Wayne Bickerdike]

> EXECIO in REXX will give you the record count in stem zero

I believe only by reading the entire file.

On Fri, May 15, 2020 at 8:02 AM Charles Mills  wrote:

> > EXECIO in REXX will give you the record count in stem zero
>
> I believe only by reading the entire file.
>
> Charles
>

Agree Charles. It's sort of hidden and would need a large memory allocation
for the stem.

>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Wayne Bickerdike
> Sent: Thursday, May 14, 2020 2:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there any z/OS API to get byte file size for non-VSAM,
> non-zFS, non-database files?
>
> EXECIO in REXX will give you the record count in stem zero. For FB you
> obtain LRECL using LENGTH function. Multiply the two. No good for VB, so
> that would require reading whole file.
>
>
>
>
> On Fri, May 15, 2020, 07:05 Gerhard adam  wrote:
>
> >
> >
> >
> >
> > Really?  There’s lots that it could do?  So why not just read the
> > DSCB for how much is free and do the calculation that has been on every
> > 3390 Reference card for 30 years
> > This is done all the time and in a variety of ways.  This problem was
> > readily assessed for decades using a subroutine.  This has always been
> > something that could readily be done until people start putting language
> > restrictions on it.  It isn’t that the info isn’t available, it is simply
> > that the information isn’t available given the restrictions placed on the
> > problem
> >
> >
> >
> > Get Outlook for iOS
> >
> >
> >
> >
> >
> >
> > On Thu, May 14, 2020 at 1:56 PM -0700, "Charles Mills"  >
> > wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > There is lots it could do! Make a decision on "strategy" based on the
> > volume of input, for example. Do I process it all or cut off after 'n'
> > records and do more on the next run? Do I read the file into an in-memory
> > table and access records there, or do I load it into a VSAM file for
> direct
> > access? Do I invoke an external sort or use an internal sort? Or a
> thousand
> > other things.
> >
> > It is wrong as @Shmuel points out to preclude questioning the necessity
> of
> > doing something exactly as the OP suggests. It is equally wrong to assume
> > there could be no good reason for doing it the OP's way.
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Gerhard adam
> > Sent: Thursday, May 14, 2020 11:52 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM,
> > non-zFS, non-database files?
> >
> >
> >
> >
> >
> > It is easy to say that a COBOL program needs to “know” this but
> it
> > is nonsense since there is nothing a COBOL program can do with this info.
> > If it turns out to really be necessary then a subroutine can be written
> > (as it has been done for decades) to provide this information.
> > If the question is simply to bitch about why z/OS does do this
> > automatically via a call or something then the complaint is directed to
> the
> > wrong group
> >
> > --
> > 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
>


-- 
Wayne V. Bickerdike

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