Re: Separate SMPe environments for maintenance levels

[Brian Westerman]

I honestly had never considered doing it this way (build one environment and 
then clone the updated copies), I always cloned and then updated that clone, 
but it makes sense that this would work just as well.  It might even be more 
effective, although I my way has the advantage of being able to fall back both 
SMP/e and clone wise, whereas I think having just one service area would mean 
no SMP/e fallback (without a lot of work).  I'll have to give this a try one 
time and see how it goes.

Brian

On Fri, 12 Jun 2020 08:53:32 -0400, Kurt Quackenbush  wrote:

>On 6/11/2020 11:38 AM, Bill Giannelli wrote:
>> I want to setup separate SMPe environments, say 3 for different maintenance 
>> levels. One matching production then 2 others for maintenance levels "coming 
>> next". My question is, when I what to update my PROD environment with one of 
>> the other maintenance levels, do I need to go thru receive, apply, accept 
>> that I would have done in the "prior" SMPe environment? Or is there a 
>> quicker way to "synch" up the 2 environments?
>
>As many have already suggested, you should consider updating one SMP/E
>environment with RECEIVE and APPLY, then clone this environment to
>create or replace others.  There are many existing variations on the
>mechanics of this clone process.
>
>If you do not already have an SMP/E environment cloning process that you
>like in place, you should take a look at z/OSMF Software Management.  It
>provides a Deploy operation that will clone your SMP/E environment,
>taking care of renaming data sets, zones, updating DDDEF entries, etc.
>
>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

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

ALTER preceded structured programming and hostile to it was Re: Goto Statements AND COBOL OPTIMIZATION

[Clark Morris]

[Default] On 11 Jun 2020 16:17:47 -0700, in bit.listserv.ibm-main
rreyno...@cix.co.uk (Rupert Reynolds) wrote:

>I lost faith COBOL and finallly became a PL/1 biggot when I was told that
>ALTER GOTO was introduced to help support structured programmng :-)

As someone who made extensive use ALTER x-exit TO y, GO TO x because
of PERFORM code generation on DOS360 and small partitions, I guarantee
you the construct preceded structured programming and was less than
friendly to maintenance programmers.  I rewrote more than one of my
programs when partitions grew to be structured and eliminate ALTER
statements.

Clark Morris
>
>Rupert
>
>On Thu, Jun 11, 2020, 01:07 Tom Ross  wrote:
>
>> >The addition of EXIT PARAGRAPH
>> >and EXIT SECTION have eliminated most of the reasons for use of GO TO
>> >in COBOL.  I would be interested in any corrections to my
>> >understanding by those responsible for the COBOL compiler. =20
>>
>> I partially agree, Clark, but what really made it easy to get rid of GOTOs
>> in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM
>> CYCLE!
>> These were added to the Standard with COBOL 2014 and implemented by IBM in
>> Enterprise
>> COBOL for z/OS V5.2
>>
>> Cheers,
>> TomR  >> COBOL is the Language of the Future! <<
>>
>> --
>> 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: How is Passive FTP with TLS and NAT supposed to work?

[Gibney, Dave]

In my case, it  was and is long stable FTPS jobs using standard files and no 
knowledgeable staff with time to refit to stfp.
 About a decade ago, I experimented with the idea of wrapping a PROC around the 
whole process.  Ran out of available time to solve all issues.
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Friday, June 12, 2020 1:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How is Passive FTP with TLS and NAT supposed to work?
> 
> On Fri, 12 Jun 2020 18:21:47 +, Gibney, Dave wrote:
> 
> >Aside from, I think this is still true, absent Dovetail extensions, the
> >requirement that SFTP only works with ZFS/HFS files
> >>
> What's the intended recipient?  If desktop or Open Systems, zFS/HFS should
> be acceptable.  If z/OS, cumbersomely flatten with TRSMAIN or TSO
> TRANSMIT; copy to zFS and SFTP.
> 
> >> There are other things, I'm sure I'm forgetting.  Switch to SFTP, and
> >> life gets much easier--most of the time.
> 
> There's some echo here of the "retire mainframe" thread.  z/OS doesn't
> "play well with others."
> 
> -- 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: How is Passive FTP with TLS and NAT supposed to work?

[Charles Mills]

I am gathering from reading the RFC that that 227 Entering Passive Mode 
(10,200,40,20,8,106) is a verbatim message from the server, and for the 
question "what *does* the server send?" the answer is "that 227 message."

Is that correct?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, June 12, 2020 3:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How is Passive FTP with TLS and NAT supposed to work?

Thanks all! Thanks much! Let me try to do one reply here to hold down the noise.

> active mode is the one using PORT; passive mode uses PASV

Thank you! It's a detail but I want to have the details right. Details are of 
the essence here. What *exactly* does the server send? On the client end I see

SC1373 initDsConnection: entered 
SC2848 sendCmd: entered  
EZA1701I >>> PASV
SC3311 getReply: entered 
SC4479 getNextReply: entered with waitForData = TRUE 
227 Entering Passive Mode (10,200,40,20,8,106)   

Where *exactly* did the client get that 10.200.40.20 from? What *does* the 
serve send to convey "open your data connection on this address"?

In other news:

- "Switching to another type of FTP" is non-trivial because the use of FTP is 
embedded in another product that builds control files on the fly. It would be a 
development project to use "a different FTP." Not out of the question, but a 
development project nonetheless.
- Both ends are z/OS FWIW. There is a mix of "legacy" and zFS. That is all 
under control presently.
- I guess "IBM" SFTP does not support legacy datasets but Dovetail SFTP does? 
Is that right? 
- Big question on SFTP: does it support anything like SITE FILETYPE=JES/GET 
jcl_file system_messages ? That is, submit a job and wait for completion? 
Without that it is a re-architecting, not a re=writing project.
- No program objects at this point but possibly in the future.
- Yes, having to install another product is a HUGE obstacle. Not impossible, 
not saying Dovetail is not wonderfulness, just the reality of sales is that 
"you have to install this other product in order to try our product" is always 
a huge obstacle.
- > FTP's dual port architecture is simply a nightmare. Yeah, it always seemed 
so to me. Why do you need two sessions -- by default initiated in opposite 
directions -- to transfer both files and control information?

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

Re: How is Passive FTP with TLS and NAT supposed to work?

[Charles Mills]

Thanks all! Thanks much! Let me try to do one reply here to hold down the noise.

> active mode is the one using PORT; passive mode uses PASV

Thank you! It's a detail but I want to have the details right. Details are of 
the essence here. What *exactly* does the server send? On the client end I see

SC1373 initDsConnection: entered 
SC2848 sendCmd: entered  
EZA1701I >>> PASV
SC3311 getReply: entered 
SC4479 getNextReply: entered with waitForData = TRUE 
227 Entering Passive Mode (10,200,40,20,8,106)   

Where *exactly* did the client get that 10.200.40.20 from? What *does* the 
serve send to convey "open your data connection on this address"?

In other news:

- "Switching to another type of FTP" is non-trivial because the use of FTP is 
embedded in another product that builds control files on the fly. It would be a 
development project to use "a different FTP." Not out of the question, but a 
development project nonetheless.
- Both ends are z/OS FWIW. There is a mix of "legacy" and zFS. That is all 
under control presently.
- I guess "IBM" SFTP does not support legacy datasets but Dovetail SFTP does? 
Is that right? 
- Big question on SFTP: does it support anything like SITE FILETYPE=JES/GET 
jcl_file system_messages ? That is, submit a job and wait for completion? 
Without that it is a re-architecting, not a re=writing project.
- No program objects at this point but possibly in the future.
- Yes, having to install another product is a HUGE obstacle. Not impossible, 
not saying Dovetail is not wonderfulness, just the reality of sales is that 
"you have to install this other product in order to try our product" is always 
a huge obstacle.
- > FTP's dual port architecture is simply a nightmare. Yeah, it always seemed 
so to me. Why do you need two sessions -- by default initiated in opposite 
directions -- to transfer both files and control information?

Charles

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

Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[Seymour J Metz]

Some of the entertaining horror stories were not funny at the time. Take the 
JES2 and TSO Command Package packaging errors, thinly disguised at 
http://mason.gmu.edu/~smetz3/humor/PUT.Process.html; I was definitely not 
amused at the time.

My favorite was "But COBOL doesn't use registers."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Friday, June 12, 2020 5:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

Volvo Truck NA, for whom I worked 14 years, had a sort of DOS-101 class for
all our end users who were trying to figure out how to use the PCs newly on
their desks.  Some of them actually seemed to pay attention, and came back
to their cubicles understanding, for instance, what a root directory is and
why it isn't a good idea to have all their documents there.  So they'd start
looking through their hard drive's root directory and deleting old stuff.
Harvard-Graphics documents: move them or delete them.  Old WordPerfect
documents: if they're old enough, dump 'em.  Here are a couple of utilities
they never got around to using:  Delete them.  COMMAND.COM ... wait,
"COMMAND.COM"?  What's that?  Another utility I never use; out it goes.

This is not the end of the world.  Any copy of COMMAND.COM will work;
there's no need to carefully match the correct version with the OS on the
victim's machine.  But one day a coworker was leaving our location, on his
way to the 3rd floor to replace someone's COMMAND.COM and loudly wondering
why the #!$@ users couldn't leave their %#@* files the @#*&! alone.  I
expostulated:  "Randy, relax.  This is an easy fix.  And these guys who're
doing this, they're the guys that'll learn eventually, and be..." well, one
of the users Mr Metz admonishes us (correctly) to cherish.  "In six months
you'll be able to talk to this guy on the phone, instead of looking over his
shoulder, and say "I dunno, maybe it's in the Windows directory; go look
there", instead of saying "Ok, type this: cee dee colon backslash ess wye
[and so on]...have you hit  yet?  Hit ...".  I like the
knowledgeable ones better.  The others give us the entertaining horror
stories, but I don't mind investing time in training the ones who want to
learn.  That's actually one of the things I found most rewarding about
end-user support.  What ended up driving me out were the users who
steadfastly declined to have their problems explained.

(If you're playing on-line games and run across a character named "Teacher",
there's a good chance it's me.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* I think everyone who chooses to stay out of politics (which is your
right) should make a mental note of where they would draw the line and feel
it necessary to get involved. Then ask yourself:  Is it possible that point
already arrived, but it happened too slowly to notice?  -Chris Evans */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Friday, June 12, 2020 12:39

On the flip side, there are some users who know what they are doing and give
you the data that you need to resolve the problem. Cherish them.

--
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: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[Bob Bridges]

Volvo Truck NA, for whom I worked 14 years, had a sort of DOS-101 class for
all our end users who were trying to figure out how to use the PCs newly on
their desks.  Some of them actually seemed to pay attention, and came back
to their cubicles understanding, for instance, what a root directory is and
why it isn't a good idea to have all their documents there.  So they'd start
looking through their hard drive's root directory and deleting old stuff.
Harvard-Graphics documents: move them or delete them.  Old WordPerfect
documents: if they're old enough, dump 'em.  Here are a couple of utilities
they never got around to using:  Delete them.  COMMAND.COM ... wait,
"COMMAND.COM"?  What's that?  Another utility I never use; out it goes.

This is not the end of the world.  Any copy of COMMAND.COM will work;
there's no need to carefully match the correct version with the OS on the
victim's machine.  But one day a coworker was leaving our location, on his
way to the 3rd floor to replace someone's COMMAND.COM and loudly wondering
why the #!$@ users couldn't leave their %#@* files the @#*&! alone.  I
expostulated:  "Randy, relax.  This is an easy fix.  And these guys who're
doing this, they're the guys that'll learn eventually, and be..." well, one
of the users Mr Metz admonishes us (correctly) to cherish.  "In six months
you'll be able to talk to this guy on the phone, instead of looking over his
shoulder, and say "I dunno, maybe it's in the Windows directory; go look
there", instead of saying "Ok, type this: cee dee colon backslash ess wye
[and so on]...have you hit  yet?  Hit ...".  I like the
knowledgeable ones better.  The others give us the entertaining horror
stories, but I don't mind investing time in training the ones who want to
learn.  That's actually one of the things I found most rewarding about
end-user support.  What ended up driving me out were the users who
steadfastly declined to have their problems explained.

(If you're playing on-line games and run across a character named "Teacher",
there's a good chance it's me.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* I think everyone who chooses to stay out of politics (which is your
right) should make a mental note of where they would draw the line and feel
it necessary to get involved. Then ask yourself:  Is it possible that point
already arrived, but it happened too slowly to notice?  -Chris Evans */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Friday, June 12, 2020 12:39

On the flip side, there are some users who know what they are doing and give
you the data that you need to resolve the problem. Cherish them.

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

Re: Don't Hire Chuck Norris was Re: restart GIMSMP in unpack step

[Art Gutowski]

On Wed, 10 Jun 2020 22:32:31 +0300, Binyamin Dissen 
 wrote:

>On Wed, 10 Jun 2020 15:18:40 -0300 Clark Morris  wrote:
>
>:>[Default] On 10 Jun 2020 07:43:41 -0700, in bit.listserv.ibm-main
>:>ku...@us.ibm.com (Kurt Quackenbush) wrote:
>:>
>:>>> snip
>:>>Kurt Quackenbush -- IBM, SMP/E Development
>:>>Chuck Norris never uses CHECK when he applies PTFs.
>:>
>:>Don't Hire Chuck Norris for any systems work.
>
>Well..
>
>Back  years ago, it was much faster to backup the resvol+smp datasets,
>do the apply, and then do a restore than the APPLY CHECK.
>
>Now, APPLYing to the running system ...

Chuck Norris doesn't need to APPLY PTFs.  He just stares down the console until 
the code straightens itself out.

Art

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

Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[Don Leahy]

Many years ago when my organization was developing thousands of online
screens for our IMS applications, I tried to get our screen design
standards committee to implement a standard that would have required a
message id to appear beside every error message displayed on the screen.
They flatly refused to consider the idea.

On Fri, Jun 12, 2020 at 12:39 Seymour J Metz  wrote:

> I was once involved with a lady who had been director of user support, and
> thought that she deserved a medal for putting up with it.
>
> On the flip side, there are some users who know what they are doing and
> give you the data that you need to resolve the problem. Cherish them.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of R.S. [r.skoru...@bremultibank.com.pl]
> Sent: Friday, June 12, 2020 7:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Messages & Codes (was Re: "Everyone wants to retire
> mainframes")
>
> W dniu 12.06.2020 o 12:59, Seymour J Metz pisze:
> > Well, if they come from a world where there is no messages manual, it
> may not occur to them to RTFM; that should be part of their initial
> training, but we all know how generous education budgets are these days.
>
> I teach mainframe courses in Poland, including "Mainframe and z/OS
> Introduction". One of the topics I present is documentation, messages,
> and WAY OF WORK. I really need to explain it is good idea to read
> sysout, analyze messages, check them in documentation.
> People are trying to use google, of course not for "IEC030I", but rather
> for "my job fails - IEBGENER is broken". And they are looking for some
> forum where other newbies answer incorrectly to bad questions. ;-)
> As a "bonus" topic on JCL course we have problem investigation - I have
> several cases with typical errors and the task is to find the
> explanation in the documentation. OK, find and *understand*.
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18,
> 00-950
> Warszawa,
> http://secure-web.cisco.com/1L9zMAWn44gXBosl23ryFmmZRlPD7Hv5DJW4XkIYhu4U-bJHTAkbq1IflALO_5lB90MpKRZRiY4EGohWX0pPn7Ei9qIFrpdjqjOHwNHJJefm6AcRkT6_TG3Z7stIm88b_S0PQijMnusrQbWUGpgHAQHK92hFNITpR9VlVTVAwouUfUdQxKHpURC4AVi25z5Sq-3RPqdUjXbZeqf8XHmPLt4sh0V_E2lD4TFsSLvTcrkhXq7P8gaN26Cf8aJTiXV5IfftDORgfSvc6rCJpQPvyaaJIvdD_smHOa3pYMecsPFoRe6hXZoG4N1gHjE-YAAapcKnIDOIXEmxOj_4gEjs8aAlta0olJCQq4tkyDqQEBzRbLhgjbdlTNNSmw9T7TUhJmFgH5PndgF2R-AK-oYsj2JFbpiPliOO_WaCcvmWNJhrM_gtwRCQZv0pp3E4TgvP5/http%3A%2F%2Fwww.mBank.pl,
> e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział
> Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18,
> 00-950
> Warszawa,
> http://secure-web.cisco.com/1L9zMAWn44gXBosl23ryFmmZRlPD7Hv5DJW4XkIYhu4U-bJHTAkbq1IflALO_5lB90MpKRZRiY4EGohWX0pPn7Ei9qIFrpdjqjOHwNHJJefm6AcRkT6_TG3Z7stIm88b_S0PQijMnusrQbWUGpgHAQHK92hFNITpR9VlVTVAwouUfUdQxKHpURC4AVi25z5Sq-3RPqdUjXbZeqf8XHmPLt4sh0V_E2lD4TFsSLvTcrkhXq7P8gaN26Cf8aJTiXV5IfftDORgfSvc6rCJpQPvyaaJIvdD_smHOa3pYMecsPFoRe6hXZoG4N1gHjE-YAAapcKnIDOIXEmxOj_4gEjs8aAlta0olJCQq4tkyDqQEBzRbLhgjbdlTNNSmw9T7TUhJmFgH5PndgF2R-AK-oYsj2JFbpiPliOO_WaCcvmWNJhrM_gtwRCQZv0pp3E4TgvP5/http%3A%2F%2Fwww.mBank.pl,
> e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw,
> 12th Commercial Division of the National Court Register, KRS 025237,
> NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
> 169.401.468 as at 1 January 2020.
>
> --
> For IBM-MAIN subscribe / signoff 

Re: How is Passive FTP with TLS and NAT supposed to work?

[Paul Gilmartin]

On Fri, 12 Jun 2020 20:46:49 +, Jackson, Rob wrote:

>Before I found out about Co:Z I used shell scripts and REXX in OMVS to copy 
>the files back and forth from MVS datasets to OMVS file systems (if sending to 
>the mainframe, they would follow up the copy with a SSH and execute a script 
>with a table of DSNs with DCBs to copy to a MVS dataset . . . or supply their 
>own DCB and dataset name).  It was very cumbersome indeed.  Co:Z makes all 
>that go away; it's simple to install, implement, and use.  Highly recommended.
>
How does it handle a program object library in a PDSE?  Or should
I presume FSVO "makes all that go away"?

Must both the sender and the recipient have Co:Z installed?  That might
be a business obstacle.

-- gil

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

Re: How is Passive FTP with TLS and NAT supposed to work?

[Jackson, Rob]

Before I found out about Co:Z I used shell scripts and REXX in OMVS to copy the 
files back and forth from MVS datasets to OMVS file systems (if sending to the 
mainframe, they would follow up the copy with a SSH and execute a script with a 
table of DSNs with DCBs to copy to a MVS dataset . . . or supply their own DCB 
and dataset name).  It was very cumbersome indeed.  Co:Z makes all that go 
away; it's simple to install, implement, and use.  Highly recommended.

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, June 12, 2020 4:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How is Passive FTP with TLS and NAT supposed to work?

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

On Fri, 12 Jun 2020 18:21:47 +, Gibney, Dave wrote:

>Aside from, I think this is still true, absent Dovetail extensions, the 
>requirement that SFTP only works with ZFS/HFS files
>>
What's the intended recipient?  If desktop or Open Systems, zFS/HFS should be 
acceptable.  If z/OS, cumbersomely flatten with TRSMAIN or TSO TRANSMIT; copy 
to zFS and SFTP.

>> There are other things, I'm sure I'm forgetting.  Switch to SFTP, and 
>> life gets much easier--most of the time.

There's some echo here of the "retire mainframe" thread.  z/OS doesn't "play 
well with others."

-- gil

--
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: How is Passive FTP with TLS and NAT supposed to work?

[Paul Gilmartin]

On Fri, 12 Jun 2020 18:21:47 +, Gibney, Dave wrote:

>Aside from, I think this is still true, absent Dovetail extensions, the 
>requirement that SFTP only works with ZFS/HFS files
>>  
What's the intended recipient?  If desktop or Open Systems, zFS/HFS should
be acceptable.  If z/OS, cumbersomely flatten with TRSMAIN or TSO TRANSMIT;
copy to zFS and SFTP.

>> There are other things, I'm sure I'm forgetting.  Switch to SFTP, and life 
>> gets
>> much easier--most of the time.

There's some echo here of the "retire mainframe" thread.  z/OS doesn't "play
well with others."

-- gil

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

Re: How is Passive FTP with TLS and NAT supposed to work?

[Seymour J Metz]

I've never understood why RFC 4960 Stream Control Transmission Protocol (SCTP) 
didn't catch on and get exploited by a new FTP protocol.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jackson, Rob [rwjack...@firsthorizon.com]
Sent: Friday, June 12, 2020 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How is Passive FTP with TLS and NAT supposed to work?

Well, your point is made und understood, but active mode is the one using PORT; 
passive mode uses PASV.  They both have their FW/load balancer issues.

We tend to use a variety of "fixes" for the various issues, given our 
convoluted (typical?) environment.  EPSV can help.  Some clients have the 
option to ignore PASV IP returned.  Our load balancers host our server certs in 
some cases so they can decrypt and modify the IP.  Our MFT proxy cluster has 
multiple nodes of FTP server adapter pairs, and each can be defined to return 
the same IP in the PASV response (they are session-break proxies, so they don't 
use the MFT servers' certs for encryption; they use their own); this IP would 
be the exposed forwarding VIP on the internet.

There are other things, I'm sure I'm forgetting.  Switch to SFTP, and life gets 
much easier--most of the time.

First Horizon Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, June 12, 2020 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How is Passive FTP with TLS and NAT supposed to work?

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

X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both urgent 
for us and perhaps a little obscure.

With Passive FTP, the server uses a PORT command to say to the client "open the 
data connection on this IP address." Unfortunately with NAT that is an internal 
address that is meaningless at the client. Many firewalls or routers that 
support NAT are apparently smart enough to translate that PORT command from an 
internal to an external address, and everything works wonderfully.

The wrinkle comes with TLS: the control connection is encrypted and 
inaccessible to the firewall or router.

Enter CCC:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha
lz001/ftpcastlsrfclevel.htm
https://secure-web.cisco.com/1XiMpdy7YXR-qJrSax9Cfz6Tkc-XqxJhBDV0eW0mQfjMw62un15xXVivwXbA9XzBQA0DcZVGFk4rkS8GCnMjxCrQ1C9CF_Gzg7xXzRAzLCCC8ec_rGjSEBfqJhBLPCvzNvJ3QH5UJMjevLqbV3NzuRnnQ3wWgu_Mw6x60j6INpAC8VNwQcHaZTqvxgPK0g00dy68Nu9hbVhUiGXPWOz-cZ2EgKIKYmU9Vn5VE3UxQ5arhR8dF2xQEKrOKz_oS1SAPS-rG5dI8Nvn0wpwUMUzh7wmoQ3xrqNqiczFA6gczyF-bStlOQYaMkNEa6rDmthBjsHuJhap6js7FB-ftEM0Ua8_WgotL7MuMsogUVDS69DGPq8y2JnseDH0nMtLCN6_SH960zKssv5t9STlJY09k8xal2jrt3A9T5FhwPUOpX1idMpkolxOldKP4G_qSgzHK9RJz652lxNFv0LerbUbYgA/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4217#page-19

CCC says "stop encrypting the control connection (so the router or firewall can 
see and translate it).

Apparently -- and this is where my knowledge gets fuzzy -- the RFC now requires 
that the partners close the control connection at that point, but z/OS FTP 
perhaps does not support that (?).

CCC has security red flags all over it, which is understandable, and it looks 
like we may be encountering a firewall or router that does not support it, or 
perhaps does not support the non-RFC version of it.

I am asking here "what is the 'right' answer?" How is passive FTP supposed to 
work over a TLS session with NAT in effect?

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: SMPe Apply not working

[Jesse 1 Robinson]

(Re-posting because ???)

I can't locate the original post in this saga, which mentioned a lot of 'no 
applicable FMID' messages. I'm curious how that happened. When we order general 
(mass) maintenance, RECEIVE FROMNETWORK examines our SMPE environment and looks 
only for PTFs that are in fact applicable. It ignores fixes that are already 
RECEIVED and chooses fixes as needed by installed products. There should be 
very few 'no applicable' messages. The reported problem calls into question 
OP's ordering process. 

Specifically, if specific PTFs are ordered by number, it's up to the customer 
to vet the list. The only situation I can recall that requires this manual 
intervention is the rare case where a product cannot be APPLIED because of an 
error hold on the FMID itself. In that case, RECEIVE FROMNETWORK does not 
acknowledge the need for maintenance because the FMID is not installed. The 
fixing PTF must be ordered and installed by name along with the FMID, after 
which RFN will resume its role.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Friday, June 12, 2020 4:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SMPe Apply not working

CAUTION EXTERNAL EMAIL

I really appreciate everyone's help here!
The issue I had I believe was that I failed to specify FORFMID.
However, I need to take a step back and review my SMPe environment.
The CSI was handed off to me and I am finding some things wrong, like missing 
FMIDs for some of my base products.
thank you
Bill

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

Re: missing FMIDs

[Jesse 1 Robinson]

I can't locate the original post in this saga, which mentioned a lot of 'no 
applicable FMID' messages. I'm curious how that happened. When we order general 
(mass) maintenance, RECEIVE FROMNETWORK examines our SMPE environment and looks 
only for PTFs that are in fact applicable. It ignores fixes that are already 
RECEIVED and chooses fixes as needed by installed products. There should be 
very few 'no applicable' messages. The reported problem calls into question 
OP's ordering process. 

Specifically, if specific PTFs are ordered by number, it's up to the customer 
to vet the list. The only situation I can recall that requires this manual 
intervention is the rare case where a product cannot be APPLIED because of an 
error hold on the FMID itself. In that case, RECEIVE FROMNETWORK does not 
acknowledge the need for maintenance because the FMID is not installed. The 
fixing PTF must be ordered and installed by name along with the FMID, after 
which RFN will resume its role. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Friday, June 12, 2020 8:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: missing FMIDs

CAUTION EXTERNAL EMAIL

so I need to reorder it all over again?
thanks
Bill

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

Re: How is Passive FTP with TLS and NAT supposed to work?

[Gibney, Dave]

We live behind an f5 Load Balancer. It knows our certificates and can 
decrypt/recrypt to determine the PORT. We flat don't do active FTPS

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Charles Mills
> Sent: Friday, June 12, 2020 11:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How is Passive FTP with TLS and NAT supposed to work?
> 
> X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both
> urgent for us and perhaps a little obscure.
> 
> With Passive FTP, the server uses a PORT command to say to the client "open
> the data connection on this IP address." Unfortunately with NAT that is an
> internal address that is meaningless at the client. Many firewalls or routers
> that support NAT are apparently smart enough to translate that PORT
> command from an internal to an external address, and everything works
> wonderfully.
> 
> The wrinkle comes with TLS: the control connection is encrypted and
> inaccessible to the firewall or router.
> 
> Enter CCC:
> https://urldefense.com/v3/__https://www.ibm.com/support/knowledgece
> nter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha__;!!JmPEgBY0HMszNaDT!4GFT57hI
> EMxPnyEcFR2djCexl1wVxTZKmL93Rb-QYqbEZ85Iosv_oseQGLlj0A$
> lz001/ftpcastlsrfclevel.htm
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc4217*page-
> 19__;Iw!!JmPEgBY0HMszNaDT!4GFT57hIEMxPnyEcFR2djCexl1wVxTZKmL93R
> b-QYqbEZ85Iosv_osfVrkck8g$
> 
> CCC says "stop encrypting the control connection (so the router or firewall
> can see and translate it).
> 
> Apparently -- and this is where my knowledge gets fuzzy -- the RFC now
> requires that the partners close the control connection at that point, but
> z/OS FTP perhaps does not support that (?).
> 
> CCC has security red flags all over it, which is understandable, and it looks 
> like
> we may be encountering a firewall or router that does not support it, or
> perhaps does not support the non-RFC version of it.
> 
> I am asking here "what is the 'right' answer?" How is passive FTP supposed to
> work over a TLS session with NAT in effect?
> 
> 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: How is Passive FTP with TLS and NAT supposed to work?

[Gibney, Dave]

Aside from, I think this is still true, absent Dovetail extensions, the 
requirement that SFTP only works with ZFS/HFS files
> 
> There are other things, I'm sure I'm forgetting.  Switch to SFTP, and life 
> gets
> much easier--most of the time.
> 
> First Horizon Bank
> Mainframe Technical Support
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Charles Mills
> Sent: Friday, June 12, 2020 2:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How is Passive FTP with TLS and NAT supposed to work?
> 
> [External Email. Exercise caution when clicking links or opening attachments.]
> 
> X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both
> urgent for us and perhaps a little obscure.
> 
> With Passive FTP, the server uses a PORT command to say to the client "open
> the data connection on this IP address." Unfortunately with NAT that is an
> internal address that is meaningless at the client. Many firewalls or routers
> that support NAT are apparently smart enough to translate that PORT
> command from an internal to an external address, and everything works
> wonderfully.
> 
> The wrinkle comes with TLS: the control connection is encrypted and
> inaccessible to the firewall or router.
> 
> Enter CCC:
> https://urldefense.com/v3/__https://www.ibm.com/support/knowledgece
> nter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha__;!!JmPEgBY0HMszNaDT!-
> 06qLbj3iAJvLUmVpYTxCYdOLC2h3vao1713bsoyuv6dekXwEPzQAxiTIwQt9Q$
> lz001/ftpcastlsrfclevel.htm
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc4217*page-
> 19__;Iw!!JmPEgBY0HMszNaDT!-
> 06qLbj3iAJvLUmVpYTxCYdOLC2h3vao1713bsoyuv6dekXwEPzQAxhEdET62Q$
> 
> CCC says "stop encrypting the control connection (so the router or firewall
> can see and translate it).
> 
> Apparently -- and this is where my knowledge gets fuzzy -- the RFC now
> requires that the partners close the control connection at that point, but
> z/OS FTP perhaps does not support that (?).
> 
> CCC has security red flags all over it, which is understandable, and it looks 
> like
> we may be encountering a firewall or router that does not support it, or
> perhaps does not support the non-RFC version of it.
> 
> I am asking here "what is the 'right' answer?" How is passive FTP supposed to
> work over a TLS session with NAT in effect?
> 
> 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: How is Passive FTP with TLS and NAT supposed to work?

[Kirk Wolf]

How about after throwing firewalls in to the mix?   FTP's dual port
architecture is simply a nightmare.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com


On Fri, Jun 12, 2020 at 1:01 PM Charles Mills  wrote:

> X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both
> urgent for us and perhaps a little obscure.
>
> With Passive FTP, the server uses a PORT command to say to the client "open
> the data connection on this IP address." Unfortunately with NAT that is an
> internal address that is meaningless at the client. Many firewalls or
> routers that support NAT are apparently smart enough to translate that PORT
> command from an internal to an external address, and everything works
> wonderfully.
>
> The wrinkle comes with TLS: the control connection is encrypted and
> inaccessible to the firewall or router.
>
> Enter CCC:
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha
> lz001/ftpcastlsrfclevel.htm
> 
> https://tools.ietf.org/html/rfc4217#page-19
>
> CCC says "stop encrypting the control connection (so the router or firewall
> can see and translate it).
>
> Apparently -- and this is where my knowledge gets fuzzy -- the RFC now
> requires that the partners close the control connection at that point, but
> z/OS FTP perhaps does not support that (?).
>
> CCC has security red flags all over it, which is understandable, and it
> looks like we may be encountering a firewall or router that does not
> support
> it, or perhaps does not support the non-RFC version of it.
>
> I am asking here "what is the 'right' answer?" How is passive FTP supposed
> to work over a TLS session with NAT in effect?
>
> 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: How is Passive FTP with TLS and NAT supposed to work?

[Jackson, Rob]

Well, your point is made und understood, but active mode is the one using PORT; 
passive mode uses PASV.  They both have their FW/load balancer issues.

We tend to use a variety of "fixes" for the various issues, given our 
convoluted (typical?) environment.  EPSV can help.  Some clients have the 
option to ignore PASV IP returned.  Our load balancers host our server certs in 
some cases so they can decrypt and modify the IP.  Our MFT proxy cluster has 
multiple nodes of FTP server adapter pairs, and each can be defined to return 
the same IP in the PASV response (they are session-break proxies, so they don't 
use the MFT servers' certs for encryption; they use their own); this IP would 
be the exposed forwarding VIP on the internet.

There are other things, I'm sure I'm forgetting.  Switch to SFTP, and life gets 
much easier--most of the time. 

First Horizon Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, June 12, 2020 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How is Passive FTP with TLS and NAT supposed to work?

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

X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both urgent 
for us and perhaps a little obscure.

With Passive FTP, the server uses a PORT command to say to the client "open the 
data connection on this IP address." Unfortunately with NAT that is an internal 
address that is meaningless at the client. Many firewalls or routers that 
support NAT are apparently smart enough to translate that PORT command from an 
internal to an external address, and everything works wonderfully.

The wrinkle comes with TLS: the control connection is encrypted and 
inaccessible to the firewall or router.

Enter CCC:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha
lz001/ftpcastlsrfclevel.htm
https://tools.ietf.org/html/rfc4217#page-19

CCC says "stop encrypting the control connection (so the router or firewall can 
see and translate it).

Apparently -- and this is where my knowledge gets fuzzy -- the RFC now requires 
that the partners close the control connection at that point, but z/OS FTP 
perhaps does not support that (?).

CCC has security red flags all over it, which is understandable, and it looks 
like we may be encountering a firewall or router that does not support it, or 
perhaps does not support the non-RFC version of it.

I am asking here "what is the 'right' answer?" How is passive FTP supposed to 
work over a TLS session with NAT in effect?

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

How is Passive FTP with TLS and NAT supposed to work?

[Charles Mills]

X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both
urgent for us and perhaps a little obscure.

With Passive FTP, the server uses a PORT command to say to the client "open
the data connection on this IP address." Unfortunately with NAT that is an
internal address that is meaningless at the client. Many firewalls or
routers that support NAT are apparently smart enough to translate that PORT
command from an internal to an external address, and everything works
wonderfully.

The wrinkle comes with TLS: the control connection is encrypted and
inaccessible to the firewall or router.

Enter CCC:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha
lz001/ftpcastlsrfclevel.htm
https://tools.ietf.org/html/rfc4217#page-19

CCC says "stop encrypting the control connection (so the router or firewall
can see and translate it).

Apparently -- and this is where my knowledge gets fuzzy -- the RFC now
requires that the partners close the control connection at that point, but
z/OS FTP perhaps does not support that (?).

CCC has security red flags all over it, which is understandable, and it
looks like we may be encountering a firewall or router that does not support
it, or perhaps does not support the non-RFC version of it.

I am asking here "what is the 'right' answer?" How is passive FTP supposed
to work over a TLS session with NAT in effect?

Charles 

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

Re: Goto Statements AND COBOL OPTIMIZATION

[Rupert Reynolds]

Confession: before I was a PL/1 bigot, I was an Assembler H bigot (now I'm
both) :-)

Rupert

On Fri, Jun 12, 2020, 05:10 Bob Bridges  wrote:

> Heck, I was a PL/1 bigot from the start.  There are other languages I
> like, but I remember PL/1 with a kind of rosy glow - possibly because I
> never use it any more.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* I think everyone who chooses to stay out of politics (which is your
> right) should make a mental note of where they would draw the line and feel
> it necessary to get involved. Then ask yourself:  Is it possible that point
> already arrived, but it happened too slowly to notice?  -Chris Evans */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rupert Reynolds
> Sent: Thursday, June 11, 2020 19:17
>
> I lost faith COBOL and finallly became a PL/1 biggot when I was told that
> ALTER GOTO was introduced to help support structured programmng :-)
>
> --
> 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: missing FMIDs

[Jousma, David]

No.   I have z/OS(Z038) and Data Virtualization Manager (P115) installed in the 
same CSI and Target/dlib zones.

_
Dave Jousma
AVP | Manager, Systems 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 
Seymour J Metz
Sent: Friday, June 12, 2020 12:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: missing FMIDs

**CAUTION EXTERNAL EMAIL**

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

Don't you still need a separate CSI for each SREL?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bill Giannelli [billgianne...@gmail.com]
Sent: Friday, June 12, 2020 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: missing FMIDs

So I had a CSI setup and provided for by someone else. As I am going thru it it 
seems there are FMIDs for a couple of products missing:
DB2 BASE Z/OS
HDREC10 DB2 RACF EXIT Z/OS
HIYCC10 DB2 IMS ATTACH Z/OS
HIZCC10 DB2 SUBSYS INIT Z/OS
JDBCC1Z DB2 12 VUE
JDBCC12 DB2 JDBC/SQLJ Z/OS

Db2 QMF for z/OS V12
HHPCC10 QMF HPO
JYQCC10 QMF ANALYTICS TSO

If I order maintenance supplying an "installed Software Report" will the 
missing FMIDs be ordered?
thanks
Bill

--
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 **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: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[Seymour J Metz]

I was once involved with a lady who had been director of user support, and 
thought that she deserved a medal for putting up with it.

On the flip side, there are some users who know what they are doing and give 
you the data that you need to resolve the problem. Cherish them.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
R.S. [r.skoru...@bremultibank.com.pl]
Sent: Friday, June 12, 2020 7:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

W dniu 12.06.2020 o 12:59, Seymour J Metz pisze:
> Well, if they come from a world where there is no messages manual, it may not 
> occur to them to RTFM; that should be part of their initial training, but we 
> all know how generous education budgets are these days.

I teach mainframe courses in Poland, including "Mainframe and z/OS
Introduction". One of the topics I present is documentation, messages,
and WAY OF WORK. I really need to explain it is good idea to read
sysout, analyze messages, check them in documentation.
People are trying to use google, of course not for "IEC030I", but rather
for "my job fails - IEBGENER is broken". And they are looking for some
forum where other newbies answer incorrectly to bad questions. ;-)
As a "bonus" topic on JCL course we have problem investigation - I have
several cases with typical errors and the task is to find the
explanation in the documentation. OK, find and *understand*.


--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1L9zMAWn44gXBosl23ryFmmZRlPD7Hv5DJW4XkIYhu4U-bJHTAkbq1IflALO_5lB90MpKRZRiY4EGohWX0pPn7Ei9qIFrpdjqjOHwNHJJefm6AcRkT6_TG3Z7stIm88b_S0PQijMnusrQbWUGpgHAQHK92hFNITpR9VlVTVAwouUfUdQxKHpURC4AVi25z5Sq-3RPqdUjXbZeqf8XHmPLt4sh0V_E2lD4TFsSLvTcrkhXq7P8gaN26Cf8aJTiXV5IfftDORgfSvc6rCJpQPvyaaJIvdD_smHOa3pYMecsPFoRe6hXZoG4N1gHjE-YAAapcKnIDOIXEmxOj_4gEjs8aAlta0olJCQq4tkyDqQEBzRbLhgjbdlTNNSmw9T7TUhJmFgH5PndgF2R-AK-oYsj2JFbpiPliOO_WaCcvmWNJhrM_gtwRCQZv0pp3E4TgvP5/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 
169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1L9zMAWn44gXBosl23ryFmmZRlPD7Hv5DJW4XkIYhu4U-bJHTAkbq1IflALO_5lB90MpKRZRiY4EGohWX0pPn7Ei9qIFrpdjqjOHwNHJJefm6AcRkT6_TG3Z7stIm88b_S0PQijMnusrQbWUGpgHAQHK92hFNITpR9VlVTVAwouUfUdQxKHpURC4AVi25z5Sq-3RPqdUjXbZeqf8XHmPLt4sh0V_E2lD4TFsSLvTcrkhXq7P8gaN26Cf8aJTiXV5IfftDORgfSvc6rCJpQPvyaaJIvdD_smHOa3pYMecsPFoRe6hXZoG4N1gHjE-YAAapcKnIDOIXEmxOj_4gEjs8aAlta0olJCQq4tkyDqQEBzRbLhgjbdlTNNSmw9T7TUhJmFgH5PndgF2R-AK-oYsj2JFbpiPliOO_WaCcvmWNJhrM_gtwRCQZv0pp3E4TgvP5/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th 
Commercial Division of the National Court Register, KRS 025237, NIP: 
526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 
January 2020.

--
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: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[Seymour J Metz]

Did he get his start as a Tech Writer for COBOL (E)?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Herring, Bobby [bherr...@txfb-ins.com]
Sent: Friday, June 12, 2020 9:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

We used to run a product called SPIFFY by Isogon. It was bought by IBM and 
renamed to Dataset Commander. I was actually told by the IBMer supporting the 
product that they didn't have a messages manual. He said the messages were 
self-explanatory. And he was serious.

I tried to explain that if they were truly that self-explanatory, then I 
wouldn't be opening incidents with them for problems.

Bobby Herring
Texas Farm Bureau Insurance

From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, June 12, 2020 6:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Messages & Codes (was Re: "Everyone wants to retire 
mainframes")

CAUTION: This email message originated from outside the organization. Do not 
click on links or open attachments unless you recognize the sender and know the 
content is safe.

> 4. Message description in the book is more than "Something is wrong.
Try again later".

That may be true now: I still recall with rage "The following messages are self 
explanatory."


--
Shmuel (Seymour J.) Metz


[http://secure-web.cisco.com/18w9NIprfVfmEn1Oozof2EaxrwO8nCMxU5L4MVMCykMtC3xrvmdoNiU7VgJo427-qwV5vbA-IFNJp3LhFL2g7XSMNh5aafnrW4h8v01GFSy7uJWGotGrutdSqf2euDU_tKe1vsxXgUe9D8a13hl43qk8q4wQGA7lTHKqsCzchq3zFn796S3NL2P_9G0779dYZqO-q3Yze9kJcrg7yFEsN0LoNBbZuFVjqCzUib6Ryf0S_j4CjAKEmEaMeGeVrCdFHsSn7EWnTB3jFKmAaTt1C5mzeMAwfMw3p9d7YVNlepCUKkZ_95DV45l4R9Z8vzMXw0mMRpue3ZC-Eb3d2XIEEec8kCX1rneRFZMcZjL7fS7vNg3BwnNsIAfNy_zJeB6tcigth_mVRkTdGxJHCaGM62wmOTcNbXKTvAYs21KANNyp1ID1uMAdrurEdz_EdYSs8/http%3A%2F%2Fwww.txfb-ins.com%2FTFBICImages%2Fjdpower.jpg]
http://secure-web.cisco.com/1KA__pf3Y-lIixjWfMiART9oVESn-lxiareUORQgTpCOUMx4QT2P8qnGkSO7BjthCbZf9I_RWzOu3jrpsKqXyP5IJG0W5wIpuIFU8tvYk7Scjvn7EX82D2xJN1EZneVT_8AXldmBmglq8fXNgrr81WjYZHo0QTQnrPOu0vCTszT8sbuhFcFBzfrwK4X2G2Kh1lvcr9IaIrU4Wn2ynNfT7YLArzuFDVGJlyBkXqSMKcQOY4Dxa6By4xuzC3cgWXxkEFXOJyrBHbItAq-Og3Cr0twuwjnaLiaCzmtilaKuDSOFMwrb0Oy2NQHzRKsu4zigyjl4PHMNWsI7I4n2f-0zGxdFbj3twFCXfrRgEb3Reaqj-vdo-O6Rh7T9v4a6OUBi9hricZs9sH4VxeKNDGz9M82tSYsfwfBMOwWHrtTezK8_iz5tLtdygn2t03cNhBGjr/http%3A%2F%2FWWW.TXFB-INS.COM

CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is 
covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 
2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in 
error, do not read it. If you are not the intended recipient, you are hereby 
notified that any retention, dissemination, distribution, or copying of this 
communication is strictly prohibited. Please reply to the sender that you have 
received the message in error, then delete it. Thank you. '

--
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: missing FMIDs

[Seymour J Metz]

Don't you still need a separate CSI for each SREL?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bill Giannelli [billgianne...@gmail.com]
Sent: Friday, June 12, 2020 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: missing FMIDs

So I had a CSI setup and provided for by someone else. As I am going thru it it 
seems there are FMIDs for a couple of products missing:
DB2 BASE Z/OS
HDREC10 DB2 RACF EXIT Z/OS
HIYCC10 DB2 IMS ATTACH Z/OS
HIZCC10 DB2 SUBSYS INIT Z/OS
JDBCC1Z DB2 12 VUE
JDBCC12 DB2 JDBC/SQLJ Z/OS

Db2 QMF for z/OS V12
HHPCC10 QMF HPO
JYQCC10 QMF ANALYTICS TSO

If I order maintenance supplying an "installed Software Report" will the 
missing FMIDs be ordered?
thanks
Bill

--
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: missing FMIDs

[Lizette Koehler]

Bill,

Make sure you are working with your licensing team.  Some products have 
different charges and your Licensing team and/or Purchasing departments would 
not like any surprise billing due to what you are ordering.

You probably should confirm what you are ordering with your management team

Lizette


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Friday, June 12, 2020 8:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: missing FMIDs

so I need to reorder it all over again?
thanks
Bill

--
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: missing FMIDs

[Carmen Vitullo]

if you require these products, at the very least you need to order those 
products not the entire suite 
be careful what you order, I see you're running 
JDBCC1Z DB2 12 VUE 
VUE is special pricing and whatever you order and install needs to support that 
VUE contract 
as Binyamin mentioned, at this point I'd be starting to ask questions about the 
product and what your contract specifies 


Carmen Vitullo 

- Original Message -

From: "Bill Giannelli"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, June 12, 2020 10:27:21 AM 
Subject: Re: missing FMIDs 

so I need to reorder it all over again? 
thanks 
Bill 

-- 
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: missing FMIDs

[Bill Giannelli]

so I need to reorder it all over again?
thanks
Bill

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

Re: missing FMIDs

[Carmen Vitullo]

If I'm reading this right, you're using a CSI or a CSI report that does not 
contain the FMIDs you need to appy maint to ? 
using Shopz you have the option of ordering the products you need without using 
a CSI report. if you create, and upload the CSI report to SHOPZ based on what 
you've said you will not get the missing FMIDS or maint. 
select do not use a report for this order 



Carmen Vitullo 

- Original Message -

From: "Bill Giannelli"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, June 12, 2020 10:13:31 AM 
Subject: missing FMIDs 

So I had a CSI setup and provided for by someone else. As I am going thru it it 
seems there are FMIDs for a couple of products missing: 
DB2 BASE Z/OS 
HDREC10 DB2 RACF EXIT Z/OS 
HIYCC10 DB2 IMS ATTACH Z/OS 
HIZCC10 DB2 SUBSYS INIT Z/OS 
JDBCC1Z DB2 12 VUE 
JDBCC12 DB2 JDBC/SQLJ Z/OS 

Db2 QMF for z/OS V12 
HHPCC10 QMF HPO 
JYQCC10 QMF ANALYTICS TSO 

If I order maintenance supplying an "installed Software Report" will the 
missing FMIDs be ordered? 
thanks 
Bill 

-- 
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: missing FMIDs

[Binyamin Dissen]

I don't know how you were "given" the setup, but it is quite possible that
there are multiple GLOBAL CSI's. If you can talk to whomever set it up before
they quit, do it. Otherwise you are going to do a bit of looking around.

On Fri, 12 Jun 2020 10:13:31 -0500 Bill Giannelli 
wrote:

:>So I had a CSI setup and provided for by someone else. As I am going thru it 
it seems there are FMIDs for a couple of products missing:
:>DB2 BASE Z/OS
:>HDREC10   DB2 RACF EXIT Z/OS
:>HIYCC10   DB2 IMS ATTACH Z/OS
:>HIZCC10   DB2 SUBSYS INIT Z/OS
:>JDBCC1Z   DB2 12 VUE
:>JDBCC12   DB2 JDBC/SQLJ Z/OS

:>Db2 QMF for z/OS V12
:>HHPCC10   QMF HPO
:>JYQCC10   QMF ANALYTICS TSO

:>If I order maintenance supplying an "installed Software Report" will the 
missing FMIDs be ordered?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

missing FMIDs

[Bill Giannelli]

So I had a CSI setup and provided for by someone else. As I am going thru it it 
seems there are FMIDs for a couple of products missing:
DB2 BASE Z/OS
HDREC10 DB2 RACF EXIT Z/OS
HIYCC10 DB2 IMS ATTACH Z/OS
HIZCC10 DB2 SUBSYS INIT Z/OS
JDBCC1Z DB2 12 VUE
JDBCC12 DB2 JDBC/SQLJ Z/OS

Db2 QMF for z/OS V12
HHPCC10 QMF HPO
JYQCC10 QMF ANALYTICS TSO

If I order maintenance supplying an "installed Software Report" will the 
missing FMIDs be ordered?
thanks
Bill

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

Re: "Everyone wants to retire mainframes"

[Phil Smith III]

Tom Brennan wrote:
>At least in that case you can hopefully reproduce the error :)
>It's the one-time lost error messages that as a support person, you 
>sometimes have to say, "Oh well"

I call this an "anecdotal error": worth opening a ticket with as much (little) 
detail as possible and then closing immediately, so it's recorded. Get a few of 
these with the same symptom and eventually you get enough breadcrumbs to 
connect the dots. I remember a problem I tracked this way for three years, 
finally nailed it.

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

Re: [External] Re: "Everyone wants to retire mainframes"

[Phil Smith III]

Charles Mills wrote, in part:
>I never bothered -- I have always gone with (s) as in "You have %d dog(s)"

You could substitute "an integer value greater 0 and less than 2" when it's 
"1", and then "dogs" would always be correct :)

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

Re: Messages & Codes

[Charles Mills]

I think Windows supports my point. It is sold in France and Japan in French
and Japanese versions.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Timothy Sipples
Sent: Friday, June 12, 2020 12:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Messages & Codes

Charles Mills wrote:
>You have to understand national politics: "we won't buy this
>product; the error messages are in English" [not French,
>Japanese, etc.]
>Even though you are of course right, "diskette in drive" is
>more understandable to the average French speaker than
>!! Sys01475

(a) This argument would have had more credibility if MS-DOS and its 
children (Windows 95, Windows 98, etc.) had sold poorly in particular 
countries for that reason. That's not how it worked out.

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

Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[Charles Mills]

It's not the users -- they want the original (i.e., in this case, English)
documentation. It is fussbudgets in purchasing or legal.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
Sent: Friday, June 12, 2020 4:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Messages & Codes (was Re: "Everyone wants to retire
mainframes")

Well...
The only country I can imagine such approach is France.
I don't know Japan, so I cannot say.
However I met mainrame people from South America and they told me they 
orderd and use English documentation due to quality (Spanish doco is 
horrible - they said).
I have never heard about such problems from Swedish, German or Italian 
folks.
Even guys in UK use IBM documentation and understand it! Almost without 
complaints. 

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

Re: Debug Tool for recovery routine

[Joseph Reichman]

I think the MFI maybe the key as I use VTAM% I think MFI indicates a dedicated 
terminal, why because what happens is after I abend and before my recovery gets 
control 
For a split second I see tool trying to connect to a NEW terminal then I get 
debug tool screen displaying garbage with my recovery name on top. 

> On Jun 12, 2020, at 9:21 AM, Dylan Perry 
> <0300eb0a0e16-dmarc-requ...@listserv.ua.edu> wrote:
> 
> I used the standard JCL options for MFI and a steplib/job with an EQAOPTS 
> that has SVCSCREEN turned on.
> 
> //CEEOPTS   DD *
>  TEST(,,,MFI%:)
> //INSPLOG  DD SYSOUT=*  
> 
> Here are some other options that may help you debug
> 
> //$DTRAC82 DD SYSOUT=*
> //IEWDIAG  DD SYSOUT=*
> //IEWTRACE DD SYSOUT=*
> //IDIOFF   DD DUMMY   
> 
> --
> 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: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[Herring, Bobby]

We used to run a product called SPIFFY by Isogon. It was bought by IBM and 
renamed to Dataset Commander. I was actually told by the IBMer supporting the 
product that they didn't have a messages manual. He said the messages were 
self-explanatory. And he was serious.

I tried to explain that if they were truly that self-explanatory, then I 
wouldn't be opening incidents with them for problems.

Bobby Herring
Texas Farm Bureau Insurance

From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, June 12, 2020 6:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Messages & Codes (was Re: "Everyone wants to retire 
mainframes")

CAUTION: This email message originated from outside the organization. Do not 
click on links or open attachments unless you recognize the sender and know the 
content is safe.

> 4. Message description in the book is more than "Something is wrong.
Try again later".

That may be true now: I still recall with rage "The following messages are self 
explanatory."


--
Shmuel (Seymour J.) Metz


[http://www.txfb-ins.com/TFBICImages/jdpower.jpg]
WWW.TXFB-INS.COM

CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is 
covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 
2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in 
error, do not read it. If you are not the intended recipient, you are hereby 
notified that any retention, dissemination, distribution, or copying of this 
communication is strictly prohibited. Please reply to the sender that you have 
received the message in error, then delete it. Thank you. '

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

Re: Debug Tool for recovery routine

[Dylan Perry]

I used the standard JCL options for MFI and a steplib/job with an EQAOPTS that 
has SVCSCREEN turned on.

//CEEOPTS   DD *
  TEST(,,,MFI%:)
//INSPLOG  DD SYSOUT=*  

Here are some other options that may help you debug

//$DTRAC82 DD SYSOUT=*
//IEWDIAG  DD SYSOUT=*
//IEWTRACE DD SYSOUT=*
//IDIOFF   DD DUMMY

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

Re: Separate SMPe environments for maintenance levels

[Kurt Quackenbush]

On 6/11/2020 11:38 AM, Bill Giannelli wrote:

I want to setup separate SMPe environments, say 3 for different maintenance levels. One matching production 
then 2 others for maintenance levels "coming next". My question is, when I what to update my PROD 
environment with one of the other maintenance levels, do I need to go thru receive, apply, accept that I 
would have done in the "prior" SMPe environment? Or is there a quicker way to "synch" up 
the 2 environments?


As many have already suggested, you should consider updating one SMP/E 
environment with RECEIVE and APPLY, then clone this environment to 
create or replace others.  There are many existing variations on the 
mechanics of this clone process.


If you do not already have an SMP/E environment cloning process that you 
like in place, you should take a look at z/OSMF Software Management.  It 
provides a Deploy operation that will clone your SMP/E environment, 
taking care of renaming data sets, zones, updating DDDEF entries, etc.


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: DDDEFs and TARGET Datasets missing

[Carmen Vitullo]

I agree, there's a couple of documents, normally, it's been a while since I 
ordered a CBPDO and that was for the OS, IIRC there's a RIMFILE, but the doc 
should point you to an SMPREL FILE hlq.fmidid.F1 F1 F2 that has JCL to 
defined the SMP DDDEF's or an IEBCOPY job that copied that RELFILE to a PDS to 
complete the install. 




Carmen Vitullo 

- Original Message -

From: "Allan Staller"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, June 12, 2020 7:16:11 AM 
Subject: Re: DDDEFs and TARGET Datasets missing 

There should be some downloadable doc along with the order. I presume this is a 
cbpdo order, and not a Serverpac order. 

-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli 
Sent: Friday, June 12, 2020 6:24 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: DDDEFs and TARGET Datasets missing 

[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.] 

So I have another "rookie" mistake here. 
I am ordering Db2 Query Monitor z/OS v3. 
I ordered and ran the GIMSMP - Download, Unpack, Receive job which completed 
successfully (CC 0). 
Now I am trying to run the Apply Check and am failing on missing DDDEFs and 
Datasets. 
Where would I get the jcl to define the DDDEFs and datasets needed? 
thanks 
Bill 

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


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

Re: DDDEFs and TARGET Datasets missing

[Bill Giannelli]

yes this is a CBPDO order.

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

Re: SMF 71 long floating point fields

[Peter Relson]

Historically, if these fields pre-dated binary floating point (let alone 
decimal floating point), they are certainly hex float point.
That would not change.

Peter Relson
z/OS Core Technology Design


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

Re: DDDEFs and TARGET Datasets missing

[Allan Staller]

There should be some downloadable doc along with the order. I presume this is a 
cbpdo order, and not a Serverpac order.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Friday, June 12, 2020 6:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DDDEFs and TARGET Datasets missing

[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.]

So I have another "rookie" mistake here.
I am ordering Db2 Query Monitor z/OS v3.
I ordered and ran the GIMSMP - Download, Unpack, Receive job which completed 
successfully (CC 0).
Now I am trying to run the Apply Check and am failing on missing DDDEFs and 
Datasets.
Where would I get the jcl to define the DDDEFs and datasets needed?
thanks
Bill

--
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: DDDEFs and TARGET Datasets missing

[Jousma, David]

That’s why you either copy them out of the relfiles, or pull them up in VIEW 
mode, make your temporary customizations, run them, and then cancel out.   
There is usually an allocation job, a DDDEF job, a ZFS allocation & mkdir job 
(if prod has zfs), apply and accept jobs in there.

The program directory I referred you to, documents all of this, including which 
relfile to go look into to find them

_
Dave Jousma
AVP | Manager, Systems 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 
Bill Giannelli
Sent: Friday, June 12, 2020 7:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DDDEFs and TARGET Datasets missing

**CAUTION EXTERNAL EMAIL**

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

thank you for the help!
I found the job members in one of the RELFILES and can run the CQMALLOC 
CQMALLO2 CQMDDDEF CQMDDDEF2 easy enough and then hopefully run a clean apply 
check.
But I feel I am missing something here.
I cant run and apply until I run those jobs but the apply will populate those 
jobs in those PDSs.
It's like the chicken and the egg.
Bill

--
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: DDDEFs and TARGET Datasets missing

[Bill Giannelli]

thank you for the help!
I found the job members in one of the RELFILES and can run the CQMALLOC 
CQMALLO2 CQMDDDEF CQMDDDEF2 easy enough and then hopefully run a clean apply 
check.
But I feel I am missing something here.
I cant run and apply until I run those jobs but the apply will populate those 
jobs in those PDSs.
It's like the chicken and the egg.
Bill

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

Re: z114 retroactive height reduction (FC 9975) for transportation

[R.S.]

W dniu 12.06.2020 o 00:34, Christian Svensson pisze:

Hi,

A bit of a niche question maybe, but this list usually enjoys those!

I need to move my z114, and sadly I don't have the possibility of
inspecting it physically right now. I was wondering if anyone knows if it
is possible to reduce the height of the z114?
In the IMPP there is a FC 9975 which separates the top portion in the
installation, but I have no idea if my individual has that feature.
Looking at older pictures of the frame there appears to be a "cut" between
the BPA and where the battery is supposed to be, so it looks like maybe
removing the side panels, the door, and then one might be able to detach
the top - but that's hard to say for sure on the pictures.

Does anyone have any experience removing the top portion for
transportation of a z114? Or similar experiences?



The height reduction is not different machine, it is just difference in 
packaging.

So, after the machine is installed there is no difference.
Regarding you problem - you want to dismount your existing machine. 
Perhaps no under warranty.

Yes, it is possible. Is is simple? Well, I did it.
It is simpler to pay some engineers to do it *and take responsibility*, 
but it is not black magic. Some keys and screwdrivers, sheet of paper 
and vinyl tape to correctly document unplugged cables.


--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[R.S.]

Well...
The only country I can imagine such approach is France.
I don't know Japan, so I cannot say.
However I met mainrame people from South America and they told me they 
orderd and use English documentation due to quality (Spanish doco is 
horrible - they said).
I have never heard about such problems from Swedish, German or Italian 
folks.
Even guys in UK use IBM documentation and understand it! Almost without 
complaints. 



(no offence intended)

--
Radoslaw Skorupka
Lodz, Poland







W dniu 11.06.2020 o 16:12, Charles Mills pisze:

You have to understand national politics: "we won't buy this product; the
error messages are in English" [not French, Japanese, etc.]

Even though you are of course right, "diskette in drive" is more
understandable to the average French speaker than !! Sys01475

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Timothy Sipples
Sent: Thursday, June 11, 2020 1:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Messages & Codes (was Re: "Everyone wants to retire
mainframes")

This pair of error messages was a design mistake:

OS/2 !! Sys01475
OS/2 !! Sys02027

That's a case of national language considerations run amok. That was the
only pair of messages you saw on your screen when you formatted a diskette
with OS/2, left the diskette in the primary drive, and rebooted the
typical PC of that era (that didn't automatically try to boot from another
device when there was a diskette in the primary drive).

A diskette's boot sector doesn't have much room, so the designers had to
be concise. They wanted to include at least one error code, and they did.
But then instead of some portion of the planet not understanding what
happened, very nearly the entire planet didn't understand what happened.
:-)

A better design would have used a global message like this:

OS/2 SYS01475: Diskette in Drive!

That's exactly the same number of characters, assuming the new line was
one character. (If not, the colon could have been omitted.) Yes, "Diskette
in Drive!" is technically English, but even so it would have been much
more broadly, globally understood than mystery error codes.





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: DDDEFs and TARGET Datasets missing

[Jousma, David]

What I do is VIEW these RELFILES and modify the JCL, run them, then cancel out  
(Ie don’t update the data).

_
Dave Jousma
AVP | Manager, Systems 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 
Bill Giannelli
Sent: Friday, June 12, 2020 7:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DDDEFs and TARGET Datasets missing

**CAUTION EXTERNAL EMAIL**

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

In my receive job I can see the various jcl members I would need to run 
CQMALLOC, CQMDDDEF, etc. These would be put in a SCQMSAMP pds. But I dont have 
those PDSs defined yet.
Bill

--
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: DDDEFs and TARGET Datasets missing

[Jousma, David]

In your shopz order there is a publications link.  In there you will find the 
Program Directory.  In it, it documents the steps to complete the SMPE work, 
along with the sample jobs.

_
Dave Jousma
AVP | Manager, Systems 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 
Bill Giannelli
Sent: Friday, June 12, 2020 7:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DDDEFs and TARGET Datasets missing

**CAUTION EXTERNAL EMAIL**

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

So I have another "rookie" mistake here.
I am ordering Db2 Query Monitor z/OS v3.
I ordered and ran the GIMSMP - Download, Unpack, Receive job which completed 
successfully (CC 0).
Now I am trying to run the Apply Check and am failing on missing DDDEFs and 
Datasets.
Where would I get the jcl to define the DDDEFs and datasets needed? 
thanks
Bill

--
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: DDDEFs and TARGET Datasets missing

[Bill Giannelli]

In my receive job I can see the various jcl members I would need to run 
CQMALLOC, CQMDDDEF, etc. These would be put in a SCQMSAMP pds. But I dont have 
those PDSs defined yet.
Bill

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

Re: DDDEFs and TARGET Datasets missing

[Mark Jacobs]

Those jobs are usually in one of the SMP/e unloaded relfiles. The install 
documentation should have that information.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Friday, June 12, 2020 7:24 AM, Bill Giannelli  
wrote:

> So I have another "rookie" mistake here.
> I am ordering Db2 Query Monitor z/OS v3.
> I ordered and ran the GIMSMP - Download, Unpack, Receive job which completed 
> successfully (CC 0).
> Now I am trying to run the Apply Check and am failing on missing DDDEFs and 
> Datasets.
> Where would I get the jcl to define the DDDEFs and datasets needed?
> thanks
> Bill
>
> --
>
> 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

DDDEFs and TARGET Datasets missing

[Bill Giannelli]

So I have another "rookie" mistake here.
I am ordering Db2 Query Monitor z/OS v3.
I ordered and ran the GIMSMP - Download, Unpack, Receive job which completed 
successfully (CC 0).
Now I am trying to run the Apply Check and am failing on missing DDDEFs and 
Datasets.
Where would I get the jcl to define the DDDEFs and datasets needed? 
thanks
Bill

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

Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[R.S.]

W dniu 12.06.2020 o 12:59, Seymour J Metz pisze:

Well, if they come from a world where there is no messages manual, it may not 
occur to them to RTFM; that should be part of their initial training, but we 
all know how generous education budgets are these days.


I teach mainframe courses in Poland, including "Mainframe and z/OS 
Introduction". One of the topics I present is documentation, messages, 
and WAY OF WORK. I really need to explain it is good idea to read 
sysout, analyze messages, check them in documentation.
People are trying to use google, of course not for "IEC030I", but rather 
for "my job fails - IEBGENER is broken". And they are looking for some 
forum where other newbies answer incorrectly to bad questions. ;-)
As a "bonus" topic on JCL course we have problem investigation - I have 
several cases with typical errors and the task is to find the 
explanation in the documentation. OK, find and *understand*.



--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: SMPe Apply not working

[Bill Giannelli]

I really appreciate everyone's help here!
The issue I had I believe was that I failed to specify FORFMID.
However, I need to take a step back and review my SMPe environment.
The CSI was handed off to me and I am finding some things wrong, like missing 
FMIDs for some of my base products.
thank you
Bill

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

Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[Seymour J Metz]

> 4. Message description in the book is more than "Something is wrong. 
Try again later".

That may be true now: I still recall with rage "The following messages are self 
explanatory."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
R.S. [r.skoru...@bremultibank.com.pl]
Sent: Friday, June 12, 2020 4:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

Well, I wrote an article on my internal company blog, recently. It was
exactly about messages and codes.
People couldn't believe in some statements:
1. Every message has its own ID. Fortunately readers agreed that msg ID
is far better than "Oops! Something went wrong, try again later".
2. Every message is documented, and there is "Messages and Codes"
bookshelf. And there are books and even bookshelves. And it was
available from Internet for 20+ years.
3. Every message ID has prefix which clearly describes that it comes
from CICS, DB2, RACF... (DFH, DSN, ICH...)
4. Message description in the book is more than "Something is wrong. Try
again later".
5. Return code has meaning. It is more than "zero vs non-zero" RC.

I wish I could put here some pictures with funny/annoying Windows
messages here.  ;-)

--
Radoslaw Skorupka
Lodz, Poland






W dniu 10.06.2020 o 22:02, Steve Smith pisze:
> I take this example as merely an example.  IBM & the software industry are
> notoriously bad at getting these right.
>
> At one end, you have "Oops, something went wrong."  -- Windows 10 (and
> yeah, the day I started using Windows 10).
>
> At the other, IDC3009I.  Sheesh.
>
> Counter to those, the IMS message doesn't seem quite so bad... it's
> (presumably) accurate, and fairly precise.  You could argue it could be
> worded more simply, or that it should provide the detailed codes.
>
> In my experience, messages get very little attention or quality review.
> I'm sure it varies a lot.
>
> sas
>
> On Wed, Jun 10, 2020 at 3:50 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
>> On Wed, 10 Jun 2020 17:02:40 +, Frank Swarbrick wrote:
>>
>>> Here's a quote from a message I posted to this list in 2009:
>>>
>>> "I have a very basic one to complain about:
>>>
>>> DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ
>>>
>>> This really means that the specified PSB DDMPPSZ is not in the specified
>> IMS library.  Why can't it just say that?  As an application programmer do
>> I really need to know that BLDL means, well, whatever it means?
>> The practice was established over a half century ago when every programmer
>> could be presumed to have at least a superficial knowledge of the entire
>> OS/360
>> reference library.  And storage was too precious to support elaborate
>> messages.
>>
>> That time has passed.
>>
>> The practice persists.
>>
>> -- gil
>>


==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1-o52lOIUVmrpRRB2evtM2aDfHTi7CkCC-0kWD68a2sG-eAou-XjkB2OaML2ka-5IWhf6Uiw7xuyYJYkoauV66tw5jUbF1xklR-4oLO5TvL353wvpksA8Ac4haRBI7lfv0zAEP-lrWPaEGBPIh8asL80fU2FU6nS8K79i9Q3cqqfR7jZdDVOXVS8b1nGysK8tHieZxjRJl1MDdOtKWLwwc2VFazJeaRrwqhbA5yLMxmGjdk_DqqyrFzUxBh47xltb-wWNmCOvYlQd7aaqWsSyrUM-MYGC9d8yjtmYj3ezEV5Hmlipf9PlkPrEpZh1OrHogHE-x3K42ZdMEP2XYXc9gra4nh9vumLJvQj_sKxuzoeTF54PHIpdRCDYopgkrsuM3OJiQi9CAqTur63dIUDTPB5wBUCVdwStEmZ8x8dqScJWINdXhHH5ylGtk-KBVELG/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 
169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 

Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[Seymour J Metz]

Well, if they come from a world where there is no messages manual, it may not 
occur to them to RTFM; that should be part of their initial training, but we 
all know how generous education budgets are these days.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Martin Packer [martin_pac...@uk.ibm.com]
Sent: Friday, June 12, 2020 5:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

I wonder, though, whether newbies can easily tell the difference between
eg "DFS" and "DFH". Particularly poignant, that pair. :-)

So we all know "ICH" and, latterly "IRR", (FSVO "latterly" :-) ) are RACF.
But do newbies pick this up quickly?

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://secure-web.cisco.com/18ahigRwLqngX6Mic0Nh_MNiy4lVK_laNQFjota3lKOAOrKYUeLiNuY0X2KbwUMr3FwtR6AEcgmtJRaeeS5MXShAfkaRb6jIDR6yFDHVX6tu-CpVjW7RywWoSGQiwCIR1sWVAozyfeLzqCeRUWQ9n81U-Ki9LqsG1VZ3Zbwh4v5vKFJ8o1yIELsSS2ZrV1b9H5CmCxAX8eibNqrWm2JYg-Akd5mIzgHTOaon4wXVz1H1blluzSIpyf2fdQZmIIo-1HURZLFKantP_gsI8MOGgcjAJcS2FmFLOSYGHohpfhrdYTH1_O04B0um7VPeiZ3YZ1sK_nZ3VAWD7R1r8MHs6-d61nEPdNsbVR4i6Uw598pYqtprTiNmhk2PI6OFroSyMdX8mTY64SVO89pWGikLY0FCtGt2yq2dn2VBYm1wKLB9eJdWRy9yKVAV390LhUSv1/https%3A%2F%2Fmainframeperformancetopics.com

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or

https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   "R.S." 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/06/2020 09:51
Subject:[EXTERNAL] Re: Messages & Codes (was Re: "Everyone wants
to retire mainframes")
Sent by:IBM Mainframe Discussion List 



Well, I wrote an article on my internal company blog, recently. It was
exactly about messages and codes.
People couldn't believe in some statements:
1. Every message has its own ID. Fortunately readers agreed that msg ID
is far better than "Oops! Something went wrong, try again later".
2. Every message is documented, and there is "Messages and Codes"
bookshelf. And there are books and even bookshelves. And it was
available from Internet for 20+ years.
3. Every message ID has prefix which clearly describes that it comes
from CICS, DB2, RACF... (DFH, DSN, ICH...)
4. Message description in the book is more than "Something is wrong. Try
again later".
5. Return code has meaning. It is more than "zero vs non-zero" RC.

I wish I could put here some pictures with funny/annoying Windows
messages here.  ;-)

--
Radoslaw Skorupka
Lodz, Poland






W dniu 10.06.2020 o 22:02, Steve Smith pisze:
> I take this example as merely an example.  IBM & the software industry
are
> notoriously bad at getting these right.
>
> At one end, you have "Oops, something went wrong."  -- Windows 10 (and
> yeah, the day I started using Windows 10).
>
> At the other, IDC3009I.  Sheesh.
>
> Counter to those, the IMS message doesn't seem quite so bad... it's
> (presumably) accurate, and fairly precise.  You could argue it could be
> worded more simply, or that it should provide the detailed codes.
>
> In my experience, messages get very little attention or quality review.
> I'm sure it varies a lot.
>
> sas
>
> On Wed, Jun 10, 2020 at 3:50 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
>> On Wed, 10 Jun 2020 17:02:40 +, Frank Swarbrick wrote:
>>
>>> Here's a quote from a message I posted to this list in 2009:
>>>
>>> "I have a very basic one to complain about:
>>>
>>> DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ
>>>
>>> This really means that the specified PSB DDMPPSZ is not in the
specified
>> IMS library.  Why can't it just say that?  As an application programmer
do
>> I really need to know that BLDL means, well, whatever it means?
>> The practice was established over a half century ago when every
programmer
>> could be presumed to have at least a superficial knowledge of the
entire
>> OS/360
>> reference library.  And storage was too precious to support elaborate
>> messages.
>>
>> That time has passed.
>>
>> The practice persists.
>>
>> -- gil
>>


==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
zapisałeś na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może
wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
(kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
narusza prawo i może podlegać karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,

Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[Martin Packer]

I wonder, though, whether newbies can easily tell the difference between 
eg "DFS" and "DFH". Particularly poignant, that pair. :-)

So we all know "ICH" and, latterly "IRR", (FSVO "latterly" :-) ) are RACF. 
But do newbies pick this up quickly?

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   "R.S." 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/06/2020 09:51
Subject:[EXTERNAL] Re: Messages & Codes (was Re: "Everyone wants 
to retire mainframes")
Sent by:IBM Mainframe Discussion List 



Well, I wrote an article on my internal company blog, recently. It was 
exactly about messages and codes.
People couldn't believe in some statements:
1. Every message has its own ID. Fortunately readers agreed that msg ID 
is far better than "Oops! Something went wrong, try again later".
2. Every message is documented, and there is "Messages and Codes" 
bookshelf. And there are books and even bookshelves. And it was 
available from Internet for 20+ years.
3. Every message ID has prefix which clearly describes that it comes 
from CICS, DB2, RACF... (DFH, DSN, ICH...)
4. Message description in the book is more than "Something is wrong. Try 
again later".
5. Return code has meaning. It is more than "zero vs non-zero" RC.

I wish I could put here some pictures with funny/annoying Windows 
messages here.  ;-)

-- 
Radoslaw Skorupka
Lodz, Poland






W dniu 10.06.2020 o 22:02, Steve Smith pisze:
> I take this example as merely an example.  IBM & the software industry 
are
> notoriously bad at getting these right.
>
> At one end, you have "Oops, something went wrong."  -- Windows 10 (and
> yeah, the day I started using Windows 10).
>
> At the other, IDC3009I.  Sheesh.
>
> Counter to those, the IMS message doesn't seem quite so bad... it's
> (presumably) accurate, and fairly precise.  You could argue it could be
> worded more simply, or that it should provide the detailed codes.
>
> In my experience, messages get very little attention or quality review.
> I'm sure it varies a lot.
>
> sas
>
> On Wed, Jun 10, 2020 at 3:50 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
>> On Wed, 10 Jun 2020 17:02:40 +, Frank Swarbrick wrote:
>>
>>> Here's a quote from a message I posted to this list in 2009:
>>>
>>> "I have a very basic one to complain about:
>>>
>>> DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ
>>>
>>> This really means that the specified PSB DDMPPSZ is not in the 
specified
>> IMS library.  Why can't it just say that?  As an application programmer 
do
>> I really need to know that BLDL means, well, whatever it means?
>> The practice was established over a half century ago when every 
programmer
>> could be presumed to have at least a superficial knowledge of the 
entire
>> OS/360
>> reference library.  And storage was too precious to support elaborate
>> messages.
>>
>> That time has passed.
>>
>> The practice persists.
>>
>> -- gil
>>


==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub 
zapisałeś na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może 
wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia 
(kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, 
narusza prawo i może podlegać karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 
526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who 
disseminates (copies, distributes) this message or takes any similar 
action, violates the law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the 
Capital City of Warsaw, 12th Commercial Division of the National Court 
Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital 
amounting to PLN 169.401.468 as at 1 January 2020.

Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")

[R.S.]

Well, I wrote an article on my internal company blog, recently. It was 
exactly about messages and codes.

People couldn't believe in some statements:
1. Every message has its own ID. Fortunately readers agreed that msg ID 
is far better than "Oops! Something went wrong, try again later".
2. Every message is documented, and there is "Messages and Codes" 
bookshelf. And there are books and even bookshelves. And it was 
available from Internet for 20+ years.
3. Every message ID has prefix which clearly describes that it comes 
from CICS, DB2, RACF... (DFH, DSN, ICH...)
4. Message description in the book is more than "Something is wrong. Try 
again later".

5. Return code has meaning. It is more than "zero vs non-zero" RC.

I wish I could put here some pictures with funny/annoying Windows 
messages here.  ;-)


--
Radoslaw Skorupka
Lodz, Poland






W dniu 10.06.2020 o 22:02, Steve Smith pisze:

I take this example as merely an example.  IBM & the software industry are
notoriously bad at getting these right.

At one end, you have "Oops, something went wrong."  -- Windows 10 (and
yeah, the day I started using Windows 10).

At the other, IDC3009I.  Sheesh.

Counter to those, the IMS message doesn't seem quite so bad... it's
(presumably) accurate, and fairly precise.  You could argue it could be
worded more simply, or that it should provide the detailed codes.

In my experience, messages get very little attention or quality review.
I'm sure it varies a lot.

sas

On Wed, Jun 10, 2020 at 3:50 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:


On Wed, 10 Jun 2020 17:02:40 +, Frank Swarbrick wrote:


Here's a quote from a message I posted to this list in 2009:

"I have a very basic one to complain about:

DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ

This really means that the specified PSB DDMPPSZ is not in the specified

IMS library.  Why can't it just say that?  As an application programmer do
I really need to know that BLDL means, well, whatever it means?
The practice was established over a half century ago when every programmer
could be presumed to have at least a superficial knowledge of the entire
OS/360
reference library.  And storage was too precious to support elaborate
messages.

That time has passed.

The practice persists.

-- gil




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: z114 retroactive height reduction (FC 9975) for transportation

[Christian Svensson]

Thanks for the clarification, very useful!

On Fri, Jun 12, 2020, 08:58 Parwez Hamid  wrote:

> Short answer - YES.
>
> FC 9975 is basically to reduce the 'height' for shipping/delivery purposes
> i.e if there isn't enough height clearance for the doorway. If a system is
> ordered with this feature, it just enlongates the install time. Nothing to
> stop 'you' to remove and reinstall the top bit. Just be careful with the
> cabling etc.
>
> Regards
>
> Parwez Hamid​
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Christian Svensson <022ad63487ef-dmarc-requ...@listserv.ua.edu>
> Sent: 11 June 2020 23:34
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: z114 retroactive height reduction (FC 9975) for transportation
>
> Hi,
>
> A bit of a niche question maybe, but this list usually enjoys those!
>
> I need to move my z114, and sadly I don't have the possibility of
> inspecting it physically right now. I was wondering if anyone knows if it
> is possible to reduce the height of the z114?
> In the IMPP there is a FC 9975 which separates the top portion in the
> installation, but I have no idea if my individual has that feature.
> Looking at older pictures of the frame there appears to be a "cut" between
> the BPA and where the battery is supposed to be, so it looks like maybe
> removing the side panels, the door, and then one might be able to detach
> the top - but that's hard to say for sure on the pictures.
>
> Does anyone have any experience removing the top portion for
> transportation of a z114? Or similar experiences?
>
> Thanks,
>
> --
> 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: SMF 71 long floating point fields

[Martin Packer]

Aargh! "Nybbles" me dummy. :-)

(And I know how this is going to go: The word "nybbles" will be debated to 
death on IBM-MAIN now. TGIF. :-) )

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Martin Packer 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/06/2020 08:08
Subject:[EXTERNAL] Re: SMF 71 long floating point fields
Sent by:IBM Mainframe Discussion List 




So, from the “RBCHAR” this is hex floating point. So with ‘45’ the First 5
nibbles of the rest are before the point. I’m wondering what this field is
that it should have a fractional part. (I guess I should look it up.)

Sent from my iPad

> On 11 Jun 2020, at 20:59, Barry Merrill  wrote:
>
> -Original Message-
> From: Barry Merrill 
> Sent: Thursday, June 11, 2020 10:02 AM
> To: 'pr...@videotron.ca' 
> Subject: RE: SMF 71 long floating point fields
>
> To SAS, they are straightforward RB8. fields with exponent and mantissa.
>
> SMF71AFB=80737.714286 RBCHAR=4513B61B6DB6DB6D
> SMF71AFB=80700.142857 RBCHAR=4513B3C249249249
> SMF71AFB=80701.285714 RBCHAR=4513B3D492492492
> SMF71AFB=80811.428571 RBCHAR=4513BAB6DB6DB6DB
> SMF71AFB=80817.571429 RBCHAR=4513BB1924924924
> SMF71AFB=80786.714286 RBCHAR=4513B92B6DB6DB6D
> SMF71AFB=80867.857143 RBCHAR=4513BE3DB6DB6DB6
> SMF71AFB=80680.428571 RBCHAR=4513B286DB6DB6DB
> SMF71AFB=80578.285714 RBCHAR=4513AC2492492492
> SMF71AFB=80708.428571 RBCHAR=4513B446DB6DB6DB
> SMF71AFB=80688.714286 RBCHAR=4513B30B6DB6DB6D
> SMF71AFB=80779 RBCHAR=4513B8B0
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
Of Pierre Fichaud
> Sent: Wednesday, June 10, 2020 6:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMF 71 long floating point fields
>
> There are many of them. I'm guessing these are hex floating point.
> Could someone confirm this or correct me ?
> Thanks, Pierre.
>
> --
> 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
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: Messages & Codes

[Timothy Sipples]

Charles Mills wrote:
>You have to understand national politics: "we won't buy this
>product; the error messages are in English" [not French,
>Japanese, etc.]
>Even though you are of course right, "diskette in drive" is
>more understandable to the average French speaker than
>!! Sys01475

(a) This argument would have had more credibility if MS-DOS and its 
children (Windows 95, Windows 98, etc.) had sold poorly in particular 
countries for that reason. That's not how it worked out.

(b) OK, try this:

SYS01475 !! Diskette / Disquette

In 32 bytes that string includes the language neutral (and still 
incomprehensible) error code *and* provides a powerful clue that covers 
English, French, German, Dutch, and some other languages exactly. It also 
covers Spanish, Italian, and Portuguese if you're willing to overlook an 
extra T. You even get the following languages pretty well or exactly (per 
Google, partial list):

Afrikaans: disket
Albanian
Basque: diskete
Bosnian: disketa
Catalan: disquet
Corsican: dischettu
Croatian: disketa
Czech: disketa
Danish
Esperanto: disketo
Estonian: diskett
Filipino
Finish: disketti
Galacian: disquete
Haitian Creole: disk
Icelandic: disklingur
Indonesian: disket
Latvian: diskete
Lithuanian: diskelis
Luxembourgish: diskett
Malay: disket
Maltese: disketta
Norwegian: diskett
Polish: dyskietka
Romanian: dischetă
Slovak: disketa
Turkish: disket

You get the idea. Anyway, this design defect (I'll call it that) is 
history.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

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

Re: SMF 71 long floating point fields

[Martin Packer]

So, from the “RBCHAR” this is hex floating point. So with ‘45’ the First 5
nibbles of the rest are before the point. I’m wondering what this field is
that it should have a fractional part. (I guess I should look it up.)

Sent from my iPad

> On 11 Jun 2020, at 20:59, Barry Merrill  wrote:
>
> -Original Message-
> From: Barry Merrill 
> Sent: Thursday, June 11, 2020 10:02 AM
> To: 'pr...@videotron.ca' 
> Subject: RE: SMF 71 long floating point fields
>
> To SAS, they are straightforward RB8. fields with exponent and mantissa.
>
> SMF71AFB=80737.714286 RBCHAR=4513B61B6DB6DB6D
> SMF71AFB=80700.142857 RBCHAR=4513B3C249249249
> SMF71AFB=80701.285714 RBCHAR=4513B3D492492492
> SMF71AFB=80811.428571 RBCHAR=4513BAB6DB6DB6DB
> SMF71AFB=80817.571429 RBCHAR=4513BB1924924924
> SMF71AFB=80786.714286 RBCHAR=4513B92B6DB6DB6D
> SMF71AFB=80867.857143 RBCHAR=4513BE3DB6DB6DB6
> SMF71AFB=80680.428571 RBCHAR=4513B286DB6DB6DB
> SMF71AFB=80578.285714 RBCHAR=4513AC2492492492
> SMF71AFB=80708.428571 RBCHAR=4513B446DB6DB6DB
> SMF71AFB=80688.714286 RBCHAR=4513B30B6DB6DB6D
> SMF71AFB=80779 RBCHAR=4513B8B0
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
Of Pierre Fichaud
> Sent: Wednesday, June 10, 2020 6:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMF 71 long floating point fields
>
> There are many of them. I'm guessing these are hex floating point.
> Could someone confirm this or correct me ?
> Thanks, Pierre.
>
> --
> 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
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: z114 retroactive height reduction (FC 9975) for transportation

[Parwez Hamid]

Short answer - YES.

FC 9975 is basically to reduce the 'height' for shipping/delivery purposes i.e 
if there isn't enough height clearance for the doorway. If a system is ordered 
with this feature, it just enlongates the install time. Nothing to stop 'you' 
to remove and reinstall the top bit. Just be careful with the cabling etc.

Regards

Parwez Hamid​


From: IBM Mainframe Discussion List  on behalf of 
Christian Svensson <022ad63487ef-dmarc-requ...@listserv.ua.edu>
Sent: 11 June 2020 23:34
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: z114 retroactive height reduction (FC 9975) for transportation

Hi,

A bit of a niche question maybe, but this list usually enjoys those!

I need to move my z114, and sadly I don't have the possibility of
inspecting it physically right now. I was wondering if anyone knows if it
is possible to reduce the height of the z114?
In the IMPP there is a FC 9975 which separates the top portion in the
installation, but I have no idea if my individual has that feature.
Looking at older pictures of the frame there appears to be a "cut" between
the BPA and where the battery is supposed to be, so it looks like maybe
removing the side panels, the door, and then one might be able to detach
the top - but that's hard to say for sure on the pictures.

Does anyone have any experience removing the top portion for
transportation of a z114? Or similar experiences?

Thanks,

--
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: Goto Statements AND COBOL OPTIMIZATION

[Tom Ross]

>Those were added w/ COBOL 2002, not 2014.  Don't give yourself too much cre=
>dit!

I noticed that too, and thought I had corrected my post, but I guess I failed!

Cheers,
TomR  >> COBOL is the Language of the Future! <<

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