Re: clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Gibney, Dave]

 I am also a small site, and I am shutting down within the year. Stopping 
at z/OS 2.3.  I am not sure what I'd have done if I had to do another z/OS 
upgrade, usually every other release. It's clear that IBM plans to make z/OSMF 
a requirement. And for zIIP-less shops, on small machines or low sub-capacity 
caps, that overhead is going to be crippling.
For large shops and those who are  using more features I guess I understand 
the direction. And, I guess it's the larger shops that pay the bills
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Brian Westerman
> Sent: Friday, January 15, 2021 9:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: clarification please - is z/OSMF required for migrating z/OS from
> v2.3 to v2.4 ?
> 
> The only real problem I have with z/OSMF is the overhead.  Several of the
> sites I manage have very small z13s systems, without zIIPs or even multiple
> CPUs, so the overhead is beyond what they can live with.
> 
> I doubt that z/OSMF will ever be the installation vehicle for z/OS, but it's 
> nice
> to have.  Also, the installation workflow is very flawed.  Luckily I looked 
> at it
> AFTER the first time I installed z/OS 2.4 or it would have taken me a lot
> longer.  Instead it was over in a day.
> 
> Brian
> 
> --
> 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: clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Brian Westerman]

The only real problem I have with z/OSMF is the overhead.  Several of the sites 
I manage have very small z13s systems, without zIIPs or even multiple CPUs, so 
the overhead is beyond what they can live with.

I doubt that z/OSMF will ever be the installation vehicle for z/OS, but it's 
nice to have.  Also, the installation workflow is very flawed.  Luckily I 
looked at it AFTER the first time I installed z/OS 2.4 or it would have taken 
me a lot longer.  Instead it was over in a day.

Brian

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

Re: No BPX-level interface for __passwd_applid? Was: Re: Code to verify LOGON password

[PINION, RICHARD W.]

It's probably a bug in SORT.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Thomas David Rivers
Sent: Friday, January 15, 2021 3:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: No BPX-level interface for __passwd_applid? Was: Re: Code to verify 
LOGON password

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

Kirk Wolf wrote:

>/*
>  Check password for a userid.
>  Note: requires program-controlled environment
>  To build:
>  c99 -o checkpass checkpass.c  i
>  extattr +p checkpass
>*/
>#define _POSIX_SOURCE
>#include 
>#include 
>#include 
>#include 
>#include 
>#include 
>
>int main(int argc, char** argv) {
>
>  if (argc != 3) {
>fprintf(stderr, "Syntax: checkpass  \n");
>return 1;
>  }
>  setenv("_EDC_ADD_ERRNO2", "1", 1);
>  if (__passwd(argv[1], argv[2], NULL)) {
>if (errno == EACCES) {
>  fprintf(stderr, "password not authorized\n");
>  return 2;
>} else {
>  fprintf(stderr, "__passwd() - %s\n", strerror(errno));
>  return 3;
>}
>  }
>  return 0;  /* no message - password valid */ }
>
>On Fri, Jan 8, 2021 at 11:19 AM Sam Golob  wrote:
>
>
>
I took a moment to dig into the BPX interface for this, I found BPX1PWD, which 
documents __passwd().  It also documents __passwd_applid(), but provides no 
interface information for it (although it discusses it as if it were a 
different interface) and provides alternatives to using the __passwd_applid BPX 
interface if you wanted to set fields in the BPX thread info yourself.

Seems like there is some doc confusion there...

I didn't find a separate BPX offset definition for __passwd_applid().

Is the _only_ way to specify the APPLID via directly setting fields in the 
BPXYTHLI thread-info  or is there an actual BPX-level interface for this?

   - Dave R. -



--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

No BPX-level interface for __passwd_applid? Was: Re: Code to verify LOGON password

[Thomas David Rivers]

Kirk Wolf wrote:


/*
 Check password for a userid.
 Note: requires program-controlled environment
 To build:
 c99 -o checkpass checkpass.c  i
 extattr +p checkpass
*/
#define _POSIX_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char** argv) {

 if (argc != 3) {
   fprintf(stderr, "Syntax: checkpass  \n");
   return 1;
 }
 setenv("_EDC_ADD_ERRNO2", "1", 1);
 if (__passwd(argv[1], argv[2], NULL)) {
   if (errno == EACCES) {
 fprintf(stderr, "password not authorized\n");
 return 2;
   } else {
 fprintf(stderr, "__passwd() - %s\n", strerror(errno));
 return 3;
   }
 }
 return 0;  /* no message - password valid */
}

On Fri, Jan 8, 2021 at 11:19 AM Sam Golob  wrote:

 


I took a moment to dig into the BPX interface for this, I found BPX1PWD,
which documents __passwd().  It also documents __passwd_applid(),
but provides no interface information for it (although it discusses it
as if it were a different interface) and provides alternatives to using
the __passwd_applid BPX interface if you wanted to set fields in the BPX
thread info yourself.

Seems like there is some doc confusion there...

I didn't find a separate BPX offset definition for __passwd_applid().

Is the _only_ way to specify the APPLID via directly setting fields in 
the BPXYTHLI

thread-info  or is there an actual BPX-level interface for this?

  - Dave R. -



--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: JCL to tar USS directory

[Paul Gilmartin]

On Fri, 15 Jan 2021 19:39:41 +, Frank Swarbrick wrote:

>
>From the z/OS Unix System Services Command Reference 
>(https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa500/bpxbatr.htm):
>
>  *   It must be a text file defined with read access only
>
So, must I have a RACF rule prohibiting write access, or what?
Or prohibit write and execute access with UNIX mode bits?
WTF!?

>  *   Specify one argument per line
>
So, not
//STDPARM DD *
PGM /bin/echo FOO BAR
/* 


>If a MVS data set is specified:
>...
>  *   The data set cannot have sequence numbers in it. 
>
OK.

>If you use the ISPF editor to edit the data set, set the sequence numbers off 
>by typing number off on the command line before you begin typing in the data.
>If sequence numbers already exist, type UNNUM to remove them and set number 
>mode off.
>
That's a "How-to", belonging in a Users Guide, not a Command Ref.,
and undoubtedly well covered in the ISPF Ref.
What about all other editors?

>  *   Trailing blanks are truncated for SYSIN and variable block data sets, 
> but not for fixed block data sets. For a fixed block data set, trailing 
> blanks will be included in the parameter text for a given argument up to the 
> end of the record.
>
Truncated for variable but not for fixed!?  Doesn't that seem backwards?
After all, the programmer can control trailing blocks for variable; not for 
fixed.

"Truncated for SYSIN ..., but not for fixed block data sets."  Doesn't that 
statement
contradict itself for fixed block SYSIN, a frequent occurrence?

Who wrote this crap?  Clearly no one proofread it with technical knowledge.

>As for the note about "JCL in-stream data set", I disagree that it belongs in 
>the JCL ref.  The behavior is specific to how BPXBATCH itself handles instream 
>data.  I don't think it's a general statement about instream data.
>
I was thinking of the "immediately  follows" qualification, not at all
specific to BPXBATCH.

-- gil

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

Re: JCL to tar USS directory

[Frank Swarbrick]

From the z/OS Unix System Services Command Reference 
(https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa500/bpxbatr.htm):


BPXBATCH supports a parameter string up to 32754 characters when called from a 
TSO command environment. Also from both a batch and TSO environment, up to 
65,536 characters can now be supplied via the a new input DD named stdparm. 
When the stdparm DD is allocated BPXBATCH will use the data found in the z/OS 
UNIX file or MVS data set associated with this DD rather that what is found on 
the parameter string or in the stdin DD. As a warning to the user, an 
informational message BPXM079I will be displayed indicating that this is 
occurring.
The stdparm DD will allow either a z/OS UNIX file, or an MVS SYSIN PDS, PDSE or 
sequential data set. The following are characteristics of the parameter data 
that can be supplied in the stdparm DD, if a z/OS UNIX file is specified:

  *   It must be a text file defined with read access only
  *   Specify one argument per line
  *   The file cannot have sequence numbers in it.
TipIf you use the ISPF editor to create the file, set the sequence numbers off 
by typing number off on the command line before you begin typing data. If 
sequence numbers already exist, type UNNUM to remove them and then type number 
off.

If a MVS data set is specified:

  *   Specify one argument per line. If the parameter string for an argument 
spans more than one line of a data set or file, this string will be divided 
into two or more arguments that are passed to the corresponding shell script or 
program.
  *   The maximum length of a single argument supplied to the program is 
32,760, which is the same as the maximum LRECL for an unspanned non-VSAM data 
set.
  *   The record format of the data set can fixed or variable (unspanned).
  *   The data set cannot have sequence numbers in it. If you use the ISPF 
editor to edit the data set, set the sequence numbers off by typing number off 
on the command line before you begin typing in the data. If sequence numbers 
already exist, type UNNUM to remove them and set number mode off.
  *   Trailing blanks are truncated for SYSIN and variable block data sets, but 
not for fixed block data sets. For a fixed block data set, trailing blanks will 
be included in the parameter text for a given argument up to the end of the 
record.

I would agree that it's not all that clear.

As for the note about "JCL in-stream data set", I disagree that it belongs in 
the JCL ref.  The behavior is specific to how BPXBATCH itself handles instream 
data.  I don't think it's a general statement about instream data.

BTW, the "copy code" is an artifact of cut and paste from a web page.  


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 15, 2021 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: JCL to tar USS directory

On Fri, 15 Jan 2021 18:22:09 +, Frank Swarbrick 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 blanks within a line.
>
>From "Guidelines for defining STDPARM", 
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa400/gfdstdparm.htm
>
Sigh.  Users Guide.  Syntactic rules belong not in a Users Guide
but in a Command Ref., which is where I looked.

>  *   [...]
>  *   An JCL in-stream data set
>
>The BPXBATCH parameter data immediately follows the STDPARM DD statement. 
>Trailing blanks are truncated for in-stream data sets, but not for other data 
>sets.
>
And that's JCL. It belongs in the JCL Ref., where it undoubtedly appears.
It shouldn't be duplicated here, except in an example.

>...
>Here is another way, placing the arguments on separate lines:
>
>//STDPARM  DD *
>SH /myscript.sh 
>
>
>/*[Copy code]
>
"[Copy code]"?

The example might instructively show a trick to concatenate (long) lines with
a command substitution:
//STDPARM  DD *
SH /myscript.sh 
$( : These lines are
  concatenated! )
/*
Is equivalent to:
//STDPARM  DD *
SH /myscript.sh 

/*

-- 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: JCL to tar USS directory

[Paul Gilmartin]

On Fri, 15 Jan 2021 18:22:09 +, Frank Swarbrick 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 blanks within a line.
>
>From "Guidelines for defining STDPARM", 
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa400/gfdstdparm.htm
> 
Sigh.  Users Guide.  Syntactic rules belong not in a Users Guide
but in a Command Ref., which is where I looked.

>  *   [...]
>  *   An JCL in-stream data set
>
>The BPXBATCH parameter data immediately follows the STDPARM DD statement. 
>Trailing blanks are truncated for in-stream data sets, but not for other data 
>sets.
>
And that's JCL. It belongs in the JCL Ref., where it undoubtedly appears.
It shouldn't be duplicated here, except in an example.

>...
>Here is another way, placing the arguments on separate lines:
>
>//STDPARM  DD *
>SH /myscript.sh 
>
>
>/*[Copy code]
>
"[Copy code]"?

The example might instructively show a trick to concatenate (long) lines with
a command substitution:
//STDPARM  DD *
SH /myscript.sh 
$( : These lines are 
  concatenated! )
/*
Is equivalent to:
//STDPARM  DD *
SH /myscript.sh 

/*

-- gil

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

Re: JCL to tar USS directory

[Frank Swarbrick]

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.

>From "Guidelines for defining STDPARM", 
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa400/gfdstdparm.htm

The wording is a bit problematic, but essentially in STDPARM only, a new line 
is treated as a space character.  You can only pass a single "line", then, when 
using STDPARM.  I also think the statement that "with the SH option, trailing 
blanks are not truncated" is not true at all.  The next "page" in the manual, 
"Ways to define STDPARM" seem to contradict this.

You can define the STDPARM parameter file by using one of the following:

  *   [...]
  *   An JCL in-stream data set

The BPXBATCH parameter data immediately follows the STDPARM DD statement. 
Trailing blanks are truncated for in-stream data sets, but not for other data 
sets.

The following is one way to define STDPARM to run the script:

//STDPARM  DD *
SH /myscript.sh   
/*

Here is another way, placing the arguments on separate lines:

//STDPARM  DD *
SH /myscript.sh 


/*[Copy code]

Result: Both of these STDPARM definitions produce the following output:









From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 15, 2021 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: JCL to tar USS directory

On Fri, 15 Jan 2021 10:12:52 -0500, Kurt Quackenbush wrote:

>On 1/14/2021 10:10 AM, Bill Giannelli wrote:
>> can anyone provide JCL to tar a USS directory?
>//PAX  EXEC PGM=BPXBATCH
>//STDPARM  DD *
>PGM /bin/pax -zvwf /u/user/paxfile.pax.Z
>/directory/to/be/paxed/
>/*
Must that second line be indented so it is not abbutted to the first, resulting 
in:
PGM /bin/pax -zvwf /u/user/paxfile.pax.Z/directory/to/be/paxed/
... ???  The manual,
z/OS  Version 2 Release 4
UNIX System Services Command Reference
IBM  SA23-2280-40

 needs clarification here.  And in

From a TSO command environment, the parameter string itself will now
support up to 32754 characters.

Doesn't TSO CALL impose a limit of 100?

Parameters to BPXBATCH can also be supplied via the stdparm DD up to a 
limit of 65,536 characters.

65,536?  65,535 is more plausible.

In addition, program_name can contain option information.

My experience has been that after SH the remainder of the PARM is passed
as the command-string to "sh -c 'command-string'".

When PGM is specified, the PARM is tokenized at blanks. The first token is
the program (path)name; remaining tokens are arguments to the program.

When PGM and program_name are specified and the specified program name
does not begin with a slash character (/), BPXBATCH prefixes the user's 
initial
working directory information to the program path name.

"initial working directory"?  I'd expect "current" working directory.
What about when SH is specified?

>//STDOUT   DD SYSOUT=*
>//STDERR   DD SYSOUT=*
>
5. BPXBATCH does not support any ddnames other than stdin , stdout, stderr,
   stdenv or stdparm. Attempting to allocate or reference any other ddnames
   will result in enqueue failures or unpredictable results. To use an MVS 
data set
   in your batch UNIX application, use "dynamic allocation", such as SVC99 
or
   the TSO ALLOC command. Also, you must remove all "static allocations"
   (ddnames referring to the MVS data set in question) from all steps in the
   batch job.

How many misstatements or misleading statements are in that paragraph?
Certainly static (JCL) allocation is less susceptible to enqueue failures than
dynamic allocation.

-- 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: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Sri h Kolusu]

> And that's the way IBM nowadays treats it's customers?

Customer? If you are a customer you would have gone thru proper channels of
opening a PMR and Level 2 would answer your questions. Please do that.

>Too bad I don't have the
> email address of Arvind Krishna, I would have loved to CC: this reply to
him!

Wow. Is that a threat?

>>As for the product you're responsible for? In 1964 IBM developed a
programming
language, PL/I, without keywords also being reserved words, alleviating the
need
to ever having to change programs when new keywords were introduced. Why
can't
you do that for SORT?

If you want something done, there are proper channels for requesting it.
RFE is one of it

https://www.ibm.com/developerworks/rfe/


> Using an adblocker is too hard? Ask yourself, would Frank Yaeger have
been
> deterred by ads when supporting an IBM product?

I use adblocker in addition to Umatrix. Thanks for your suggestion.

> especially item 4!
> And more ramblings of a nobody?

Good for you. well I don't have boast about what I did or how much I help
on this board and other helpboards.

Either way this will be my last and final reply to you and your posts.

Thanks,
Kolusu

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

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Seymour J Metz]

> I'm sure others here have looked and looked and looked at code they wrote,
> absolutely sure that it was OK, only to be informed by a colleague, after 
> he/she
> looked at it for about 42 milliseconds, that they missed out on another
> "Purloined Letter"...

Sometimes, 42 ms after I explain what the code is supposed to do I get a "duh" 
moment before he has time to spot it.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [rob...@prino.org]
Sent: Friday, January 15, 2021 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

On 2021-01-15 16:22, Sri h Kolusu wrote:
>>
>> Please don't patronise me with high "coding standards", you banned
>> me from your
>> forum when I commented on the fact that you suggested using UNSPEC()
>> to look at
>> the internal representation of z/OS HEX FLOAT values in order top
>> print them in
>> a PL/I program, and then deleted the postings to hide your own
> incompetence!
>
>
> Robert,
>
> Ya right ! And you had the audacity to call it a bug in the product even
> though you are data owner and mere checking of the data would have answered
> your own question.  I should have gone with my first instinct of just
> ignoring your rambling. That is the only thing you do.

And that's the way IBM nowadays treats it's customers? Too bad I don't have the
email address of Arvind Krishna, I would have loved to CC: this reply to him!

Then again, maybe the "Heart to Heart" program still exists, it used to
guarantee that a letter to the CEO was only read by the CEO.

And it actually worked in a grey past: after having been shoved around for
months not receiving the updates for OS/2 I was entitled to, a "Heart to Heart"
letter to Mr Palmisano did the trick,  I was contacted by a personal assistant
of the managing director of IBM UK, and two weeks later a big box with all OS/2
updates arrived!

Maybe you should have a look at
,
especially item 4!

I'm sure others here have looked and looked and looked at code they wrote,
absolutely sure that it was OK, only to be informed by a colleague, after he/she
looked at it for about 42 milliseconds, that they missed out on another
"Purloined Letter"...

And more ramblings of a nobody?

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147579
(Given the last IBM comment, not unlikely that it will be delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=100073
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=31632
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=84512
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=145001
(Planned for future release)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
(Under consideration)

As for the product you're responsible for? In 1964 IBM developed a programming
language, PL/I, without keywords also being reserved words, alleviating the need
to ever having to change programs when new keywords were introduced. Why can't
you do that for SORT?

>> And did you actually read the "...and ***someone*** came up with a
>> really very
>> elegant way of performing this task, ..." (Emphasis added...) You should
> have
>> seen, as you're also on that forum, that the solution was provided by
> Jörg
>> Findeisen!
>
> I stopped browsing that forum ever since they forced ads.

Using an adblocker is too hard? Ask yourself, would Frank Yaeger have been
deterred by ads when supporting an IBM product?

> Kudos to Jorg > findeisen for coding a solution. And the degree of elegance 
> depends. So if
> you are happy with the solution stick with it
>
 And that saves? 1 nanosecond?
>
> The question is NOT only about saving CPU cycles. The elegance you boast
> isn't seen when you code such statements.
>
>> Which is really important for something that processes 209 lines of
>> input, and
>> might at some stage process as many as 300 lines on input, and it's part
> of a
>> job that runs for about a minute, so saving a fraction of a second? And
> when
>> SORT is invoked by the viewer, the result is usually displayed when
>> my finger is
>> still next to the Enter key.
>
> As I said earlier I 

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Robert Prins]

On 2021-01-15 16:22, Sri h Kolusu wrote:


Please don't patronise me with high "coding standards", you banned
me from your
forum when I commented on the fact that you suggested using UNSPEC()
to look at
the internal representation of z/OS HEX FLOAT values in order top
print them in
a PL/I program, and then deleted the postings to hide your own

incompetence!


Robert,

Ya right ! And you had the audacity to call it a bug in the product even
though you are data owner and mere checking of the data would have answered
your own question.  I should have gone with my first instinct of just
ignoring your rambling. That is the only thing you do.


And that's the way IBM nowadays treats it's customers? Too bad I don't have the 
email address of Arvind Krishna, I would have loved to CC: this reply to him!


Then again, maybe the "Heart to Heart" program still exists, it used to 
guarantee that a letter to the CEO was only read by the CEO.


And it actually worked in a grey past: after having been shoved around for 
months not receiving the updates for OS/2 I was entitled to, a "Heart to Heart" 
letter to Mr Palmisano did the trick,  I was contacted by a personal assistant 
of the managing director of IBM UK, and two weeks later a big box with all OS/2 
updates arrived!


Maybe you should have a look at 
, 
especially item 4!


I'm sure others here have looked and looked and looked at code they wrote, 
absolutely sure that it was OK, only to be informed by a colleague, after he/she 
looked at it for about 42 milliseconds, that they missed out on another 
"Purloined Letter"...


And more ramblings of a nobody?

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147579
(Given the last IBM comment, not unlikely that it will be delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=100073 
(Delivered)


https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=31632
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=84512
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=145001
(Planned for future release)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
(Under consideration)

As for the product you're responsible for? In 1964 IBM developed a programming 
language, PL/I, without keywords also being reserved words, alleviating the need 
to ever having to change programs when new keywords were introduced. Why can't 
you do that for SORT?



And did you actually read the "...and ***someone*** came up with a
really very
elegant way of performing this task, ..." (Emphasis added...) You should

have

seen, as you're also on that forum, that the solution was provided by

Jörg

Findeisen!


I stopped browsing that forum ever since they forced ads.  


Using an adblocker is too hard? Ask yourself, would Frank Yaeger have been 
deterred by ads when supporting an IBM product?



Kudos to Jorg > findeisen for coding a solution. And the degree of elegance 
depends. So if
you are happy with the solution stick with it


And that saves? 1 nanosecond?


The question is NOT only about saving CPU cycles. The elegance you boast
isn't seen when you code such statements.


Which is really important for something that processes 209 lines of
input, and
might at some stage process as many as 300 lines on input, and it's part

of a

job that runs for about a minute, so saving a fraction of a second? And

when

SORT is invoked by the viewer, the result is usually displayed when
my finger is
still next to the Enter key.


As I said earlier I wouldn't have bothered to answer the questions from YOU
if you hadn't called an user error a bug in the product.


I guess the question marks didn't make it to your side...

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Dana Mitchell]

On Fri, 15 Jan 2021 10:34:12 -0500, Kurt Quackenbush  wrote:
>While z/OSMF is not strictly required for upgrading z/OS V2.3 to V2.4,
>it is highly recommended, specifically for the z/OS V2.4 Upgrade Workflow:
>
>https://github.com/IBM/IBM-Z-zOS/tree/master/zOS-Workflow/zOS%20V2.4%20Upgrade%20Workflow
>
>The workflow is a replacement for the former z/OS Migration books.  
>

I used the z/OSMF workflow for migrating to 2.4.  I think it would make more 
sense and be easier to use if it were arranged in the order you actually do 
stuff, instead of like the sections of the old migration guides.  For example, 
under 'Upgrading from z/OS V2R2',  there's a section for each component,  BCP, 
CIM, DFSMS, HCD,  etc.  

Then, under each component, there's sections:  
'BCP actions to perform before installing z/OS V2R4',  
'BCP actions to perform before the first IPL of z/OS V2R4',
'BCP actions to perform after the first IPL of z/OS V2R4'.   

So first you have to go through all components, and perform 'actions to perform 
before installing z/OS V2R4'. Next go back through all components, and do 
'xxx actions to perform before the first IPL',   then back through everything 
doing 'xxx actions to perform after the first IPL'

Or perhaps a sort option to sort the steps of the workflow and put all the 
'before installing'  steps together,  then all the 'before IPL'  steps together.

Dana

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

Re: JCL to tar USS directory

[Paul Gilmartin]

On Fri, 15 Jan 2021 10:12:52 -0500, Kurt Quackenbush wrote:

>On 1/14/2021 10:10 AM, Bill Giannelli wrote:
>> can anyone provide JCL to tar a USS directory?
>//PAX  EXEC PGM=BPXBATCH
>//STDPARM  DD *
>PGM /bin/pax -zvwf /u/user/paxfile.pax.Z
>/directory/to/be/paxed/
>/*
Must that second line be indented so it is not abbutted to the first, resulting 
in:
PGM /bin/pax -zvwf /u/user/paxfile.pax.Z/directory/to/be/paxed/
... ???  The manual,
z/OS  Version 2 Release 4
UNIX System Services Command Reference
IBM  SA23-2280-40

 needs clarification here.  And in 

From a TSO command environment, the parameter string itself will now
support up to 32754 characters.

Doesn't TSO CALL impose a limit of 100?

Parameters to BPXBATCH can also be supplied via the stdparm DD up to a 
limit of 65,536 characters.

65,536?  65,535 is more plausible.

In addition, program_name can contain option information.

My experience has been that after SH the remainder of the PARM is passed
as the command-string to "sh -c 'command-string'".

When PGM is specified, the PARM is tokenized at blanks. The first token is
the program (path)name; remaining tokens are arguments to the program.

When PGM and program_name are specified and the specified program name
does not begin with a slash character (/), BPXBATCH prefixes the user's 
initial
working directory information to the program path name.

"initial working directory"?  I'd expect "current" working directory.
What about when SH is specified?

>//STDOUT   DD SYSOUT=*
>//STDERR   DD SYSOUT=*
>
5. BPXBATCH does not support any ddnames other than stdin , stdout, stderr,
   stdenv or stdparm. Attempting to allocate or reference any other ddnames
   will result in enqueue failures or unpredictable results. To use an MVS 
data set
   in your batch UNIX application, use "dynamic allocation", such as SVC99 
or
   the TSO ALLOC command. Also, you must remove all "static allocations"
   (ddnames referring to the MVS data set in question) from all steps in the
   batch job.

How many misstatements or misleading statements are in that paragraph?
Certainly static (JCL) allocation is less susceptible to enqueue failures than
dynamic allocation.

-- gil

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

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Sri h Kolusu]

>
> Please don't patronise me with high "coding standards", you banned
> me from your
> forum when I commented on the fact that you suggested using UNSPEC()
> to look at
> the internal representation of z/OS HEX FLOAT values in order top
> print them in
> a PL/I program, and then deleted the postings to hide your own
incompetence!


Robert,

Ya right ! And you had the audacity to call it a bug in the product even
though you are data owner and mere checking of the data would have answered
your own question.  I should have gone with my first instinct of just
ignoring your rambling. That is the only thing you do.

> And did you actually read the "...and ***someone*** came up with a
> really very
> elegant way of performing this task, ..." (Emphasis added...) You should
have
> seen, as you're also on that forum, that the solution was provided by
Jörg
> Findeisen!

I stopped browsing that forum ever since they forced ads.  Kudos to Jorg
findeisen for coding a solution. And the degree of elegance depends. So if
you are happy with the solution stick with it

>>> And that saves? 1 nanosecond?

The question is NOT only about saving CPU cycles. The elegance you boast
isn't seen when you code such statements.

> Which is really important for something that processes 209 lines of
> input, and
> might at some stage process as many as 300 lines on input, and it's part
of a
> job that runs for about a minute, so saving a fraction of a second? And
when
> SORT is invoked by the viewer, the result is usually displayed when
> my finger is
> still next to the Enter key.

As I said earlier I wouldn't have bothered to answer the questions from YOU
if you hadn't called an user error a bug in the product.

Thanks,
Kolusu


IBM Mainframe Discussion List  wrote on
01/15/2021 10:53:50 AM:

> From: Robert Prins 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 01/15/2021 08:54 AM
> Subject: [EXTERNAL] Re: Bug in DFSORT? [WAS: Merging multiple
> records using DFSORT]
> Sent by: IBM Mainframe Discussion List 
>
> On 2021-01-15 11:50, Sri h Kolusu wrote:
> >> So what's so special about 80? 9, 41 and 44 are unique in the entire
set
> > of >sort control statements, and 80 also doesn't appear, yet replacing
44
> > by 80 >results in incorrect output.
> >
> >> I've gone over it again and again, but I'm totally clueless, unless
this
> > is >one of those bugs that nobody's encountered before(*).
> >> So, if someone can confirm the problem, or that this is a case of
Edgar
> >> Allan Poe's "The Purloined Letter", i.e. so obvious that it hides in
plain
> >> sight, please reply to this post!
> >
> > Robert,
> >
> > Let me start off with "It is NOT a BUG" and the obvious is right in
front
> > of you. As a data owner you SHOULD be in a better position to tell as
to
> > what is so special about the data at position 80.
>
> Yes, as I already wrote, it's probably a case of "The Purloined
Letter"...
>
> > To explain what is so special about 80. Open the input dataset in
> > browse/edit mode
> >
> > Issue the command F '+' 44 ALL then make a note of where exactly you
are
> > finding the specified character. Also Make a note of the number of
times
> > the character is found. (5 times)
> >
> > Hint : It is found on the FIRST line of the boxed data skipping the
first
> > set of data
> >
> > Now issue the same command but changing the position to 80
> >
> > F '+' 80 ALL
> >
> > Also make a note of how many number of times the character is found (9
> > times)
> >
> > Hint : It is found on the FIRST/SECOND/THIRD line of the boxed data
> > starting with the first set of data.
> >
> > DFSORT is merely doing what you wanted it to do. So I am not sure
comparing
> > a 5 time found data with 9 times found data is correct.
> >
> > Btw the control cards can be optimized and I am not even sure as to why
you
> > need a numeric conversion for simply sticking a constant value of
0120 ?
> > Not sure how it passed your high "coding standards"
>
> Please don't patronise me with high "coding standards", you banned
> me from your
> forum when I commented on the fact that you suggested using UNSPEC()
> to look at
> the internal representation of z/OS HEX FLOAT values in order top
> print them in
> a PL/I program, and then deleted the postings to hide your own
incompetence!
>
> And did you actually read the "...and ***someone*** came up with a
> really very
> elegant way of performing this task, ..." (Emphasis added...) You should
have
> seen, as you're also on that forum, that the solution was provided by
Jörg
> Findeisen!
>
> > INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:+120,ZD,LENGTH=4)),
> >
> > should be as simple as
> >
> > INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:C'0120')),
>
> And that saves? 1 nanosecond?
>
> > Similarly when using the substring format and searching for multiple
> > characters, it is advisable to have a comma so that it is easy to
> > understand and maintain.
> >
> > (44,1,SS,EQ,C'+|') should be  (44,1,SS,EQ,C'+,|')
>
> And how much extra time does this add to parsing the 

Re: clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Jousma, David]

" However, IBM's plan is to eventually require z/OSMF for future software 
installation.  We have not yet announced when or for which product releases, 
but it's certainly past time to start getting comfortable with z/OSMF in 
general."

Hopefully well after I retire Unless it is made really simple.   These 
days, a complete serverpac install to the point where I am applying my SMPE 
usermods, is maybe a half day's worth of work.   I get it that IBM probably 
wants to do away with the Custompac dialogs.   But please don’t do it only to 
make the process more complicated.

_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kurt Quackenbush
Sent: Friday, January 15, 2021 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: clarification please - is z/OSMF required for migrating z/OS from 
v2.3 to v2.4 ?

**CAUTION EXTERNAL EMAIL**

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

On 1/15/2021 10:00 AM, Bruce Lightsey wrote:
> I am not one of the system programmers but have been tasked with getting this 
> answer for them (and to manage them). My systems guys like SMPe and 
> ServerPacks, etc but z/OSMF is “Alienware” to them – must I tell them to get 
> over it and go with the workflow ?
While z/OSMF is not strictly required for upgrading z/OS V2.3 to V2.4, it is 
highly recommended, specifically for the z/OS V2.4 Upgrade Workflow:

https://github.com/IBM/IBM-Z-zOS/tree/master/zOS-Workflow/zOS%20V2.4%20Upgrade%20Workflow

The workflow is a replacement for the former z/OS Migration books.  If you 
insist on something that approximates a book form, on that page you can find 
links to a sample exported workflow.  The exported format is suitable for 
browsing, printing, and searching.  But really your team should take this 
opportunity to get familiar with the z/OSMF workflow.

z/OS V2.4 is installed using the familiar ServerPac method.  However, IBM's 
plan is to eventually require z/OSMF for future software installation.  We have 
not yet announced when or for which product releases, but it's certainly past 
time to start getting comfortable with z/OSMF in general.

Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when 
he applies PTFs.

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

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

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


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

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Robert Prins]

On 2021-01-15 11:50, Sri h Kolusu wrote:

So what's so special about 80? 9, 41 and 44 are unique in the entire set

of >sort control statements, and 80 also doesn't appear, yet replacing 44
by 80 >results in incorrect output.


I've gone over it again and again, but I'm totally clueless, unless this

is >one of those bugs that nobody's encountered before(*).

So, if someone can confirm the problem, or that this is a case of Edgar
Allan Poe's "The Purloined Letter", i.e. so obvious that it hides in plain
sight, please reply to this post!


Robert,

Let me start off with "It is NOT a BUG" and the obvious is right in front
of you. As a data owner you SHOULD be in a better position to tell as to
what is so special about the data at position 80.


Yes, as I already wrote, it's probably a case of "The Purloined Letter"...


To explain what is so special about 80. Open the input dataset in
browse/edit mode

Issue the command F '+' 44 ALL then make a note of where exactly you are
finding the specified character. Also Make a note of the number of times
the character is found. (5 times)

Hint : It is found on the FIRST line of the boxed data skipping the first
set of data

Now issue the same command but changing the position to 80

F '+' 80 ALL

Also make a note of how many number of times the character is found (9
times)

Hint : It is found on the FIRST/SECOND/THIRD line of the boxed data
starting with the first set of data.

DFSORT is merely doing what you wanted it to do. So I am not sure comparing
a 5 time found data with 9 times found data is correct.

Btw the control cards can be optimized and I am not even sure as to why you
need a numeric conversion for simply sticking a constant value of 0120 ?
Not sure how it passed your high "coding standards"


Please don't patronise me with high "coding standards", you banned me from your 
forum when I commented on the fact that you suggested using UNSPEC() to look at 
the internal representation of z/OS HEX FLOAT values in order top print them in 
a PL/I program, and then deleted the postings to hide your own incompetence!


And did you actually read the "...and ***someone*** came up with a really very 
elegant way of performing this task, ..." (Emphasis added...) You should have 
seen, as you're also on that forum, that the solution was provided by Jörg 
Findeisen!



INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:+120,ZD,LENGTH=4)),

should be as simple as

INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:C'0120')),


And that saves? 1 nanosecond?


Similarly when using the substring format and searching for multiple
characters, it is advisable to have a comma so that it is easy to
understand and maintain.

(44,1,SS,EQ,C'+|') should be  (44,1,SS,EQ,C'+,|')


And how much extra time does this add to parsing the string? Sheesh...


This is explained in the 2nd bullet here

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icea100/substr.htm

And just for the record, the job can be optimized and can be done easily.


Which is really important for something that processes 209 lines of input, and 
might at some stage process as many as 300 lines on input, and it's part of a 
job that runs for about a minute, so saving a fraction of a second? And when 
SORT is invoked by the viewer, the result is usually displayed when my finger is 
still next to the Enter key.


Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Kurt Quackenbush]

On 1/15/2021 10:00 AM, Bruce Lightsey wrote:

I am not one of the system programmers but have been tasked with getting this 
answer for them (and to manage them). My systems guys like SMPe and 
ServerPacks, etc but z/OSMF is “Alienware” to them – must I tell them to get 
over it and go with the workflow ?
While z/OSMF is not strictly required for upgrading z/OS V2.3 to V2.4, 
it is highly recommended, specifically for the z/OS V2.4 Upgrade Workflow:


https://github.com/IBM/IBM-Z-zOS/tree/master/zOS-Workflow/zOS%20V2.4%20Upgrade%20Workflow

The workflow is a replacement for the former z/OS Migration books.  If 
you insist on something that approximates a book form, on that page you 
can find links to a sample exported workflow.  The exported format is 
suitable for browsing, printing, and searching.  But really your team 
should take this opportunity to get familiar with the z/OSMF workflow.


z/OS V2.4 is installed using the familiar ServerPac method.  However, 
IBM's plan is to eventually require z/OSMF for future software 
installation.  We have not yet announced when or for which product 
releases, but it's certainly past time to start getting comfortable with 
z/OSMF in general.


Kurt Quackenbush -- IBM, SMP/E Development
Chuck Norris never uses CHECK when he applies PTFs.

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

Re: [External] clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Pommier, Rex]

No, it is not required.  I upgraded from 2.2 to 2.4 6 months ago using a 
serverpack.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bruce Lightsey
Sent: Friday, January 15, 2021 9:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] clarification please - is z/OSMF required for migrating 
z/OS from v2.3 to v2.4 ?

I am not one of the system programmers but have been tasked with getting this 
answer for them (and to manage them). My systems guys like SMPe and 
ServerPacks, etc but z/OSMF is “Alienware” to them – must I tell them to get 
over it and go with the workflow ?

Thanks
Bruce



Bruce Lightsey
Database Manager
MS Department of Information Technology Services
601-432-8144 | www.its.ms.gov

DISCLAIMER: This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the system 
manager. This message contains confidential information and is intended only 
for the individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited


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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Steve Beaver]

The biggest thing is to the ZFS mounted that contains all the objects for the 
zOS for the release in question. 

Once you do that it takes a little customization and adding the STC’s 

Sent from my iPhone

> On Jan 15, 2021, at 09:04, Richards, Robert B. (CTR) 
> <01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Yes, if they want the upgrade workflow. No, at this time the ServerPac is 
> still doable outside of z/OSMF.
> 
> 
> 
> z/OSMF is definitely the future. They've procrastinated long enough! 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Bruce Lightsey
> Sent: Friday, January 15, 2021 10:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: clarification please - is z/OSMF required for migrating z/OS from 
> v2.3 to v2.4 ?
> 
> 
> 
> I am not one of the system programmers but have been tasked with getting this 
> answer for them (and to manage them). My systems guys like SMPe and 
> ServerPacks, etc but z/OSMF is “Alienware” to them – must I tell them to get 
> over it and go with the workflow ?
> 
> 
> 
> Thanks
> 
> Bruce
> 
> 
> 
> 
> 
> 
> 
> Bruce Lightsey
> 
> Database Manager
> 
> MS Department of Information Technology Services
> 
> 601-432-8144 | www.its.ms.gov
> 
> 
> 
> DISCLAIMER: This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they are 
> addressed. If you have received this email in error please notify the system 
> manager. This message contains confidential information and is intended only 
> for the individual named. If you are not the named addressee you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this e-mail by mistake and delete 
> this e-mail from your system. If you are not the intended recipient you are 
> notified that disclosing, copying, distributing or taking any action in 
> reliance on the contents of this information is strictly prohibited
> 
> 
> 
> 
> 
> --
> 
> 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: clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Carmen Vitullo]

  
z/OSMF is not required but downloading and using the workflows into z/OSMF, 
which replaced the migration guide really helps with migration actions IMHO. 
I was very hesitant to use z/OSMF and the workflow, I found it aided in my 
migration  
Carmen Vitullo 

   

-Original Message-

From: Bruce 
To: IBM-MAIN 
Date: Friday, 15 January 2021 9:01 AM CST
Subject: clarification please - is z/OSMF required for migrating z/OS from v2.3 
to v2.4 ?

I am not one of the system programmers but have been tasked with getting this 
answer for them (and to manage them). My systems guys like SMPe and 
ServerPacks, etc but z/OSMF is “Alienware” to them – must I tell them to get 
over it and go with the workflow ? 

Thanks 
Bruce 



Bruce Lightsey
Database Manager
MS Department of Information Technology Services
601-432-8144 | www.its.ms.gov

DISCLAIMER: This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the system 
manager. This message contains confidential information and is intended only 
for the individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited


-- 
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: JCL to tar USS directory

[Kurt Quackenbush]

On 1/14/2021 10:10 AM, Bill Giannelli wrote:

can anyone provide JCL to tar a USS directory?

//PAX  EXEC PGM=BPXBATCH
//STDPARM  DD *
PGM /bin/pax -zvwf /u/user/paxfile.pax.Z
/directory/to/be/paxed/
/*
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*

Kurt Quackenbush -- IBM, SMP/E Development
Chuck Norris never uses CHECK when he applies PTFs.

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

Re: clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Richards, Robert B. (CTR)]

Yes, if they want the upgrade workflow. No, at this time the ServerPac is still 
doable outside of z/OSMF.



z/OSMF is definitely the future. They've procrastinated long enough! 



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bruce Lightsey
Sent: Friday, January 15, 2021 10:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: clarification please - is z/OSMF required for migrating z/OS from v2.3 
to v2.4 ?



I am not one of the system programmers but have been tasked with getting this 
answer for them (and to manage them). My systems guys like SMPe and 
ServerPacks, etc but z/OSMF is “Alienware” to them – must I tell them to get 
over it and go with the workflow ?



Thanks

Bruce







Bruce Lightsey

Database Manager

MS Department of Information Technology Services

601-432-8144 | www.its.ms.gov



DISCLAIMER: This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the system 
manager. This message contains confidential information and is intended only 
for the individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited





--

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

clarification please - is z/OSMF required for migrating z/OS from v2.3 to v2.4 ?

[Bruce Lightsey]

I am not one of the system programmers but have been tasked with getting this 
answer for them (and to manage them). My systems guys like SMPe and 
ServerPacks, etc but z/OSMF is “Alienware” to them – must I tell them to get 
over it and go with the workflow ?

Thanks
Bruce



Bruce Lightsey
Database Manager
MS Department of Information Technology Services
601-432-8144 | www.its.ms.gov

DISCLAIMER: This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the system 
manager. This message contains confidential information and is intended only 
for the individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited


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

Re: JCL to tar USS directory

[Paul Gilmartin]

On Fri, 15 Jan 2021 02:55:30 -0600, Jantje wrote:

>On Thu, 14 Jan 2021 09:00:21 -0600, Bill Giannelli wrote:
>
>>can anyone provide JCL to tar a USS directory?
> 
Tar is obsolescent, largely replaced by pax with added features.

>IMHO, if you are going to do anything in Unix on mainframe, you want to use 
>Co:Z from DovetailedTechnologies: https://www.dovetail.com/index.html
>
o Co:Z is generally highy recommended.
o However, some sites choose by policy not to install Co:Z.
o Therefore ISVs should avoid distributing to customers code that depends on 
Co:Z.
o BPXBATCH suffices to invoke tar/pax.
o SMP/E relies heavily on Unix on mainframe but is Co:Z free.

-- gil

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

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Sri h Kolusu]

>So what's so special about 80? 9, 41 and 44 are unique in the entire set
of >sort control statements, and 80 also doesn't appear, yet replacing 44
by 80 >results in incorrect output.

>I've gone over it again and again, but I'm totally clueless, unless this
is >one of those bugs that nobody's encountered before(*).
>So, if someone can confirm the problem, or that this is a case of Edgar
>Allan Poe's "The Purloined Letter", i.e. so obvious that it hides in plain
>sight, please reply to this post!

Robert,

Let me start off with "It is NOT a BUG" and the obvious is right in front
of you. As a data owner you SHOULD be in a better position to tell as to
what is so special about the data at position 80.

To explain what is so special about 80. Open the input dataset in
browse/edit mode

Issue the command F '+' 44 ALL then make a note of where exactly you are
finding the specified character. Also Make a note of the number of times
the character is found. (5 times)

Hint : It is found on the FIRST line of the boxed data skipping the first
set of data

Now issue the same command but changing the position to 80

F '+' 80 ALL

Also make a note of how many number of times the character is found (9
times)

Hint : It is found on the FIRST/SECOND/THIRD line of the boxed data
starting with the first set of data.

DFSORT is merely doing what you wanted it to do. So I am not sure comparing
a 5 time found data with 9 times found data is correct.

Btw the control cards can be optimized and I am not even sure as to why you
need a numeric conversion for simply sticking a constant value of 0120 ?
Not sure how it passed your high "coding standards"

INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:+120,ZD,LENGTH=4)),

should be as simple as

INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:C'0120')),

Similarly when using the substring format and searching for multiple
characters, it is advisable to have a comma so that it is easy to
understand and maintain.

(44,1,SS,EQ,C'+|') should be  (44,1,SS,EQ,C'+,|')

This is explained in the 2nd bullet here

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icea100/substr.htm

And just for the record, the job can be optimized and can be done easily.

Thanks,
 Kolusu

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

Re: CICS and COBOL DISPLAY UPON CONSOLE

[Jantje.]

On Thu, 14 Jan 2021 17:55:39 +, Frank Swarbrick 
 wrote:

>I just accidentally did a DISPLAY UPON CONSOLE statement in a CICS program

I would recommend using E C WRITE OPEARTOR if you really need to talk through 
the console.

Cheers,

Jantje.

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

Re: JCL to tar USS directory

[Jantje.]

On Thu, 14 Jan 2021 09:00:21 -0600, Bill Giannelli  
wrote:

>can anyone provide JCL to tar a USS directory?

IMHO, if you are going to do anything in Unix on mainframe, you want to use 
Co:Z from DovetailedTechnologies: https://www.dovetail.com/index.html

I am not affiliated in any way with Dovetail, except as a very happy user of 
their excellent stuff.

Cheers,

Jantje.

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