z/OS MF environment - effort estimation.

[Anil Kumar]

Hi All,

Good day. I needed expert advise on how do we calculate the numbers (effort 
estimation ) provided that we have the infrastructure that we support. Assuming 
that I have the below:

1) # of LPARs.
2) # of ISV products.
3) Automation on z/os on all LPARs.
4) Storage 
5)MIPS 
6) # of CICS regions
7) # of DB2 subsystems
8) MQ regions 
9) # of WAS
10) # of IMS subsystems 

etc.

I understand that different shops have different strategy in calculating the 
same. However I needed valuable inputs on how to start estimating. Is there any 
industry standard or best practice available. How are shops deducing #'s given 
the infrastructure that is available.

I really appreciate all your inputs in this regard. Please let me know for any 
further information required from my end. Thanks.

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

Re: z/OS MF environment - effort estimation.

[Elardus Engelbrecht]

Anil Kumar wrote:

>Good day. I needed expert advise on how do we calculate the numbers (effort 
>estimation ) 

What numbers / effort? Costs? Man-hours? CPU estimate? Licenses? 
Infrastructure? etc.? 


> ... provided that we have the infrastructure that we support. 

Are these things in place: Power (Main and UPS), Room space, Physical security?


>... Assuming that I have the below:

>1) # of LPARs.
>2) # of ISV products.
>3) Automation on z/os on all LPARs.
>4) Storage 
>5)MIPS 
>6) # of CICS regions
>7) # of DB2 subsystems
>8) MQ regions 
>9) # of WAS
>10) # of IMS subsystems 

More things to add...

 11) Network infrastructure including remote connection.
 12) Security product(s)
 13) PPRC and what else too for your storage...
 14) You forgot about DRP. This will certainly double (sort off) your 
'effort'.
 15) Workstations to access above things ...
 16) XCF, Sysplex Timers
 17) Add more toys and tools including having a 'Sandbox' LPAR for SMP/E 
and testing out products.


>I understand that different shops have different strategy in calculating the 
>same. However I needed valuable inputs on how to start estimating. 

Ask first, how much staff do you have and how much are you willing to pay or 
pulling in contractors.

How many clients / users do you have for each of those listed systems?


>Is there any industry standard or best practice available. 

Yes, there is only ONE standard, it is named 'No Standard'. You will have to 
figure out yourself what is the best for you. Perhaps there are IBM-MAIN 
members who can help you or supply you a product which can do those estimates...


>I really appreciate all your inputs in this regard. Please let me know for any 
>further information required from my end.

Ask your vendors. They know their products and can give you a ball-park figure 
of everything.

Good luck.

Groete / Greetings
Elardus Engelbrecht

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

Re: ShopZ 24/7? Maybe not so much....

[Tom Conley]

On 12/17/2017 12:52 PM, Tom Conley wrote:

On 12/17/2017 9:59 AM, Pinnacle wrote:
Thought ShopZ was supposed to be available 24/7, but it appears to be 
taking the weekend off.  Been trying to get 3 PTF's for over an hour 
now.  Not like anybody would apply maintenance on a weekend or 
anything


Regards,
Tom Conley



4 hours and counting



Finally completed at 316 minutes, or 5 hours and 16 minutes for those of 
you at home.  Can't wait until I need maint to fix a Sev 1 and run into 
this.  What a joke.  I can run Windows update anytime I want, why the 
hell can't I do that for z/OS?  We'll bring this up at SHARE yet again, 
and IBM will assure us they're working on it, they'll point to their 
99.99 uptime, and then nothing will change.  Lather, rinse, repeat.


WAKE UP IBM, THIS IS COMPLETELY UNACCEPTABLE FOR SERVICE DELIVERY!!!

Why am I so pissed?  We've been working with IBM for AT LEAST five years 
concerning 24/7 availability for both Service Delivery and IBMLink.  Yet 
we continue to have these extended outages.  No wonder people want off 
the mainframe.


Regards,
Tom Conley

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

Re: Cobol upgrade 6.2 linklist

[John McKown]

On Mon, Dec 18, 2017 at 12:20 AM, Peter Hunkeler  wrote:

> > If an auditor "pressed", then (if not also insisting on LNKAUTH=APFTAB),
> that auditor most likely was wrong.
>
>
> IMHO, those auditors were wrong. Full stop. Auditors should investigate,
> document, and suggest. Auditors should never be allowed to force something.
>

​I'm no longer allowed around auditors. I have two problems. The first is
that I tell them the absolute truth, as best as I know it. The second is
that I tell them to shove off if they start pestering me to "get this done
now, I demand you drop everything to do this for me."​



>
>
> --
> Peter Hunkeler
>
>

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: ShopZ 24/7? Maybe not so much....

[Allan Staller]

The "new tools" are neither as reliable, available or functional as those they 
are replacing


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Sunday, December 17, 2017 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ShopZ 24/7? Maybe not so much

On 12/17/2017 9:59 AM, Pinnacle wrote:
> Thought ShopZ was supposed to be available 24/7, but it appears to be
> taking the weekend off.  Been trying to get 3 PTF's for over an hour
> now.  Not like anybody would apply maintenance on a weekend or anything
>
> Regards,
> Tom Conley
>

4 hours and counting

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

::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: Track address space which is non reusable

[Brown, Duncan]

I track ASID usage with the free MXI from Rocket.  

I track it because some product leave the ASID's in a 'not-reusable' state.  I 
execute it in a batch job and create a running total of how many are available 
and how many are not-reusable.

I've been burned a couple of times when there were no more left and no new 
address spaces would start.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jake Anderson
Sent: Monday, December 18, 2017 1:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Track address space which is non reusable

'Why? Just like Lizette asked, you should also give reason why you want that 
info.'

For setting up a health checker. Sorry' i should have told earlier.




On 18-Dec-2017 11:03 AM, "Elardus Engelbrecht" < 
elardus.engelbre...@sita.co.za> wrote:

Jake Anderson wrote:

>>Is there any rexx exec or a program which can tell me the number of
Address space which are nonreusable ASID ?
>>zOS 2.2

Why? Just like Lizette asked, you should also give reason why you want that 
info.


Roger Lowe wrote:

>If I remember correctly, there should be a Health Check called "IEA_ASIDS"
which should give you the info that you are after ...

Yup, you are correct. If you have such ASIDs, you will see IEAVEH012I and 
IEAVEH001I.

Also, Mark Zelden has a REXX program 'ASIDLIST". Check his website, you should 
be able to use Mr. G. O. Ogle's fancy search thing ( :-D ) to search for it.

Groete / Greetings
Elardus Engelbrecht

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



-
CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System intends 
this e-mail message, and any attachments, to be used only by the person(s) or 
entity to which it is addressed. This message may contain confidential and/or 
legally privileged information. If the reader is not the intended recipient of 
this message or an employee or agent responsible for delivering the message to 
the intended recipient, you are hereby notified that you are prohibited from 
printing, copying, storing, disseminating or distributing this communication. 
If you received this communication in error, please delete it from your 
computer and notify the sender by reply e-mail.


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

Re: ShopZ 24/7? Maybe not so much....

[Allan Staller]

What he said!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Monday, December 18, 2017 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ShopZ 24/7? Maybe not so much

On 12/17/2017 12:52 PM, Tom Conley wrote:
> On 12/17/2017 9:59 AM, Pinnacle wrote:
>> Thought ShopZ was supposed to be available 24/7, but it appears to be
>> taking the weekend off.  Been trying to get 3 PTF's for over an hour
>> now.  Not like anybody would apply maintenance on a weekend or
>> anything
>>
>> Regards,
>> Tom Conley
>>
>
> 4 hours and counting
>

Finally completed at 316 minutes, or 5 hours and 16 minutes for those of you at 
home.  Can't wait until I need maint to fix a Sev 1 and run into this.  What a 
joke.  I can run Windows update anytime I want, why the hell can't I do that 
for z/OS?  We'll bring this up at SHARE yet again, and IBM will assure us 
they're working on it, they'll point to their
99.99 uptime, and then nothing will change.  Lather, rinse, repeat.

WAKE UP IBM, THIS IS COMPLETELY UNACCEPTABLE FOR SERVICE DELIVERY!!!

Why am I so pissed?  We've been working with IBM for AT LEAST five years 
concerning 24/7 availability for both Service Delivery and IBMLink.  Yet we 
continue to have these extended outages.  No wonder people want off the 
mainframe.

Regards,
Tom Conley

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

::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: LRS VPS Printer Replacment

[Barkow, Eileen]

I am curious as to why you want to replace VPS with another product, at least 
one which you would have to pay for anyway.
I know that Mckinney has a competing product which is probably cheaper than 
VPS, but
LRS support has always been great (when they get paid on time) and it may not 
be worth the effort to replace it.
 Especially if a lot of customized code has to be written.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zos reader
Sent: Thursday, December 14, 2017 4:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LRS VPS Printer Replacment

Hi,

We are planning to replace LRS VPS Printers to other Vendor product, I am
not aware of other vendor products in Market.

Can you all share your thoughts please.

Thanks..

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




This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.

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

Re: Track address space which is non reusable

[Michael Babcock]

Hmmm.  Already a health check for ASIDs isn’t there?   IEA_ASIDS.Lists
normal and replacement IDs. Even tells you How many have become
non-reusable since the IPL

On Mon, Dec 18, 2017 at 7:31 AM Brown, Duncan  wrote:

> I track ASID usage with the free MXI from Rocket.
>
> I track it because some product leave the ASID's in a 'not-reusable'
> state.  I execute it in a batch job and create a running total of how many
> are available and how many are not-reusable.
>
> I've been burned a couple of times when there were no more left and no new
> address spaces would start.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: Monday, December 18, 2017 1:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Track address space which is non reusable
>
> 'Why? Just like Lizette asked, you should also give reason why you want
> that info.'
>
> For setting up a health checker. Sorry' i should have told earlier.
>
>
>
>
> On 18-Dec-2017 11:03 AM, "Elardus Engelbrecht" <
> elardus.engelbre...@sita.co.za> wrote:
>
> Jake Anderson wrote:
>
> >>Is there any rexx exec or a program which can tell me the number of
> Address space which are nonreusable ASID ?
> >>zOS 2.2
>
> Why? Just like Lizette asked, you should also give reason why you want
> that info.
>
>
> Roger Lowe wrote:
>
> >If I remember correctly, there should be a Health Check called "IEA_ASIDS"
> which should give you the info that you are after ...
>
> Yup, you are correct. If you have such ASIDs, you will see IEAVEH012I and
> IEAVEH001I.
>
> Also, Mark Zelden has a REXX program 'ASIDLIST". Check his website, you
> should be able to use Mr. G. O. Ogle's fancy search thing ( :-D ) to search
> for it.
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> 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
>
>
>
> -
> CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System
> intends this e-mail message, and any attachments, to be used only by the
> person(s) or entity to which it is addressed. This message may contain
> confidential and/or legally privileged information. If the reader is not
> the intended recipient of this message or an employee or agent responsible
> for delivering the message to the intended recipient, you are hereby
> notified that you are prohibited from printing, copying, storing,
> disseminating or distributing this communication. If you received this
> communication in error, please delete it from your computer and notify the
> sender by reply e-mail.
>
>
> --
> 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: CMS style XMITMSG for Unix and other platforms

[Farley, Peter x23353]

Hi Rick,

I may not get to try your XMITMSG tool for a while due to other commitments, 
but the VM facility I miss the most is the SMSG / WAKEUP SMSG facility that 
permits "server" VM's to run and respond to remote requests from "users".  In a 
prior lifetime my coworkers and I used that facility to implement a nicely 
featured SCLM for an ISV.

I realize that a git server is the modern incarnation of that concept and git 
is certainly a much more sophisticated SCLM tool, but it would be interesting 
anyway to have something resembling SMSG / WAKEUP SMSG available in z/OS.

XMITMSG would be very helpful in a "disconnected server" setup for sure.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rick Troth
Sent: Sunday, December 17, 2017 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CMS style XMITMSG for Unix and other platforms

EXTERNAL: This email originated from outside of Broadridge. Do not click any 
links or open any attachments unless you trust the sender and know the content 
is safe.

Aaaand ... it seems to be good enough for download: 'git clone' and then 
'make tests'. Works.

https://github.com/trothr/xmitmsgx


You can also find it on Casita.Net:

http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.0.17.tar.gz


I'd like to hear back from someone trying it on USS. Should work fine 
with batch or TSO too when using flat filenames.
Realy I'd like to hear back from *anyone* (using it on, e.g., AIX or 
Linux or whatever).

-- R; <><


On 12/11/17 09:34, Rick Troth wrote:
> friends --
>
> VM/CMS has a wonderful utility driven by 'XMITMSG' (the command) and by
> APPLMSG (the macro). If you're a VMer, you know about it. If you're a
> VSE or MVS person, maybe not. It's good stuff. For (at least) the second
> time, I started putting together an XMITMSG work-alike for Unix (POSIX,
> including Linux). Anyone else interested in this? If so, please let me
> know.
>
> There are language libraries and message handlers in Unix land. I have
> yet to find one that works like XMITMSG and the APPLMSG macro with token
> replacement, enumerated messages, clear codes in the handling. Maybe
> there is such, in which case my little "xmitmsgx" project might reduce
> to simple interoperability glue code. If so, great!
>
> I WAS SHOCKED several years ago to learn that there is no equivalent
> function in z/OS. It's an incredibly elegant way to handle localization
> (national languages, regional dialects). This project should work on MVS
> too; it's simple code.
>
> If you have time and inclination to try this thing (and offer feedback
> ... or code), please holler. Thanks!
--


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


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

Re: CMS style XMITMSG for Unix and other platforms

[John McKown]

On Mon, Dec 18, 2017 at 10:26 AM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> Hi Rick,
>
> I may not get to try your XMITMSG tool for a while due to other
> commitments, but the VM facility I miss the most is the SMSG / WAKEUP SMSG
> facility that permits "server" VM's to run and respond to remote requests
> from "users".  In a prior lifetime my coworkers and I used that facility to
> implement a nicely featured SCLM for an ISV.
>
> I realize that a git server is the modern incarnation of that concept and
> git is certainly a much more sophisticated SCLM tool, but it would be
> interesting anyway to have something resembling SMSG / WAKEUP SMSG
> available in z/OS.
>

​I would guess that most software which does that would use the QEDIT macro
(
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa300/qedit.htm)
and the associated MODIFY operator command. Of course, this is not really a
"general purpose" interface for program to program (IPC) communication.
That's a good job for TCPIP or, in some ways even better, UNIX message
queues (IPC within a single OS).​



>
> XMITMSG would be very helpful in a "disconnected server" setup for sure.
>
> Peter
>


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

AW: Re: RSM Freemained Frames - When do they apply?

[Peter Hunkeler]

> RSM will free frames if available frames are in short supply.
> If you obtain a smaller amount, get it backed, and then release it, you
> may be more likely to observe the frames being retained.


I've changed the program to allocate 8KiB areas instead of 10MiB, and RSM 
decides to keep the frames upon the storage release. IPCS RSMDATA REALFRAME 
lists the freemained frames. Although this feature is pretty much useless for 
the programmer, it's nice to have seen it in action once.


Thanks again, Jim.
--
Peter Hunkeler



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

Re: Cobol upgrade 6.2 linklist

[Jesse 1 Robinson]

We steer away from dynamic linklist update as well. When Omegamon could do it 
decades ago, I chided IBM for lagging behind. Nowadays I have a different 
perspective: not how to move forward, but how to move back in case of 
unexpected trouble. So we invariably create a new library and IPL with it. In 
case of (possible but unlikely) chaos, we IPL back the old library. Whatever 
the original problem was, it could hardly be worse than getting stuck in a hot 
mess purgatory with no clear exit.  

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Monday, December 18, 2017 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Cobol upgrade 6.2 linklist

I see your points, for me, it's never been in a habit of upgrading any target 
lib's that are linklisted, did that once with some older XX products (PDS) that 
didn't act well after trying dynamically refreshing LLA and the linklist, so 
I've built my linklist lib's from my target libs, and IPL most times. 


Carmen Vitullo 

- Original Message -

From: "Jerry Whitteridge" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, December 18, 2017 12:21:55 PM
Subject: Re: Cobol upgrade 6.2 linklist 

The issue with PDSE in the linklist is related to any PDSE that is in the IPL 
linklist gets an tag to (I think it is ) XCFAS so that if you whish to do 
dynamic maintenance to a product you can take the existing library out of the 
linklist, but can't rename etc. You would then need to use a new Library name 
to put the product back into linklist. 

If you are not in the habit of doing dynamic maintenance the PDSE in the IPL 
linklist isn't an issue, and if you can use different names it's also not an 
issue. 


--
Jerry Whitteridge 

IBM Global Services
Delivery Manager
e-Mail: jerry.whitteri...@ibm.com
Cell: 602 527 4871 < Note New Phone Number 

IBM Mainframe Discussion List  wrote on
12/18/2017 11:17:01 AM: 

> From: Seymour J Metz 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 12/18/2017 11:17 AM
> Subject: Re: Cobol upgrade 6.2 linklist Sent by: IBM Mainframe 
> Discussion List 
> 
> It used to be that you couldn't have PDSE in LNKLSTxx, but could add a 
> PDSE with an automatic SETPROG command. I don't know whether that 
> restriction still exists.
> 
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.proofpoint.com/v2/url? 
> u=http-3A__mason.gmu.edu_-7Esmetz3=DwIFAw=jf_iaSHvJObTbx-
> 
siA1ZOg=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E=C2kzwWYqC2ybVmHsfpyw64D6PNfA6yu1lS3vcYix7Vo=VBOFuf9SLwZLzw4062UipuCiuQswXhRkKon3Cw5np64=
 

> 
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Carmen Vitullo 
> Sent: Friday, December 15, 2017 1:15 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Cobol upgrade 6.2 linklist
> 
> Hum , I know COBOL object modules 5+ need to be PDS/E, but I've never 
> knew about the linklist restrictions with PDS/E , so what about IBM 
> libraries in the linklist from my serverpac build?
> alway had in CPAC.PARMLIB and migrated forward. 
> 
> 
> SYS1.SHASLNKE
> 
> 
> 
> SYS1.SIEALNKE
> 
> 
> SYS1.SIEAMIGEetc
> am I taking unnecessary chances? 
> 
> 
> 
> Carmen Vitullo
> 
> - Original Message -
> 
> From: "Lizette Koehler" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Friday, December 15, 2017 11:47:57 AM
> Subject: Re: Cobol upgrade 6.2 linklist
> 
> As you will find out. Any Cobol program compiled from the Cobol 
> Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD.
> 
> If you have your application batch load library in the LINKLST then 
> you will need to move it into the place where you start other PDS/E 
> Dataset in the Linklst.
> 
> The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do not 
> have the SMSPDSx ASID available at the time the LINKLST is done.
> You have to build it after the SMSPDSx STC is up
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On 
> > Behalf Of Jake Anderson
> > Sent: Friday, December 15, 2017 5:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Cobol upgrade 6.2 linklist
> > 
> > Hi
> > 
> > A general question
> > 
> > Do you still cobol load module in linklist post upgrade to 6.2 ? 
> > 
> > Regards
> > Jake


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

Re: "make" question

[Rick Troth]

On 12/18/17 20:44, Paul Gilmartin wrote:

On Mon, 18 Dec 2017 19:47:26 -0500, Rick Troth wrote:

Anyway, it's not difficult to have your makefiles fix themselves,
converting leading 8 blanks to a tab automagically. Some of the
makefiles in and around CMS Make do exactly that: if they land on (for
example) Linux, they get run through 'sed' to convert leading 8 blanks
to a single tab.

Doesn't this break a macro definition or a dependency rule that happens to
start with 8 blanks?


I did say limited scope.
So I suppose it /could/, but IMLX I've never seen a macro nor rule that 
starts with 8 blanks.


There must have been some reason Feldman chose  instead of  
But the story I recall fondly is that after creating 'make' and turning 
it loose and then getting a good night's sleep, he fretted, "why did I 
give it such a stupid requirement?". (heavily paraphrased; "stupid" 
wording mine)




-- gil

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


-- R; <><







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

Re: ShopZ 24/7? Maybe not so much....

[Tom Conley]

On 12/18/2017 12:29 PM, Ed Jaffe wrote:

On 12/18/2017 8:30 AM, Tom Conley wrote:
We'll bring this up at SHARE yet again, and IBM will assure us they're 
working on it, they'll point to their 99.99 uptime, and then nothing 
will change.


Funny how the downtime (.001%? Really? No! That counts only "unexpected" 
outages...) always seems to occur on the weekends when sysprogs need it 
most... :-\




"Me and Eddie tiltin' at the Windmills" (sung to the tune of "Me and 
Julio Down by the Schoolyard").  Don't get me started on the outages 
always being Saturday night-Sunday morning.


Regards,
Tom Conley

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

Re: CMS style XMITMSG for Unix and other platforms

[Farley, Peter x23353]

Interesting question.  I do see a VMCF STC on our V2.1 system.  Where would one 
look to find docs on how to use it?  Comm Server docs?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Monday, December 18, 2017 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CMS style XMITMSG for Unix and other platforms

Back in the Paleolithic era IBM ported VMPC to MVS for use by TCP/IP. The 
Pascal stack has been dead for lo these many years. Is it conceivable that the 
VMCF port is still present in z/OS V2?


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


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Monday, December 18, 2017 11:26 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CMS style XMITMSG for Unix and other platforms

Hi Rick,

I may not get to try your XMITMSG tool for a while due to other commitments, 
but the VM facility I miss the most is the SMSG / WAKEUP SMSG facility that 
permits "server" VM's to run and respond to remote requests from "users".  In a 
prior lifetime my coworkers and I used that facility to implement a nicely 
featured SCLM for an ISV.

I realize that a git server is the modern incarnation of that concept and git 
is certainly a much more sophisticated SCLM tool, but it would be interesting 
anyway to have something resembling SMSG / WAKEUP SMSG available in z/OS.

XMITMSG would be very helpful in a "disconnected server" setup for sure.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rick Troth
Sent: Sunday, December 17, 2017 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CMS style XMITMSG for Unix and other platforms

Aaaand ... it seems to be good enough for download: 'git clone' and then 'make 
tests'. Works.


https://secure-web.cisco.com/1569EauQyiUBk0UI-kLr73Tuu_q0uGgwUC6o6G54m_hi6OGCs-qYYVSjKoSYKQD3QMn0V9vZwOa15GRKHwA2fN40NR5koQvP4FdEKHWoseYx0nPtvqhpiR0L8aE3PXDqQbY5FdCi5PbaxahZj6M0Li6U_CYMp41DxVmn6uoGC3SPca3uHccgCC-0NtjE3c7z_Lf2H-zkTXTnQSupTuHh-qigFpGQjwNzZ1sjyeAZh0iqsDvwqv_YVQ14wI_GWMf_pC6c9nQkldJQ9vFcEzcHKvVxDH0nvB1ZiS8MWVUv-19t9u2TA1vZXHkS8PYNwQkPMIIC8p03BvI5LR2JoskT4jT3U-7WtZI-m0AGAlBRiupDN4zUWLuTTZRAESLyQ-dLRQ5M9NDoluzk5ib5Ip8N-HJEOj4wSaS6hjT7D4ihrgL2-YmvPw0IF5TqUOltrc3k-/https%3A%2F%2Fgithub.com%2Ftrothr%2Fxmitmsgx


You can also find it on Casita.Net:

http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.0.17.tar.gz


I'd like to hear back from someone trying it on USS. Should work fine with 
batch or TSO too when using flat filenames.
Realy I'd like to hear back from *anyone* (using it on, e.g., AIX or Linux or 
whatever).

-- R; <><


On 12/11/17 09:34, Rick Troth wrote:
> friends --
>
> VM/CMS has a wonderful utility driven by 'XMITMSG' (the command) and 
> by APPLMSG (the macro). If you're a VMer, you know about it. If you're 
> a VSE or MVS person, maybe not. It's good stuff. For (at least) the 
> second time, I started putting together an XMITMSG work-alike for Unix 
> (POSIX, including Linux). Anyone else interested in this? If so, 
> please let me know.
>
> There are language libraries and message handlers in Unix land. I have 
> yet to find one that works like XMITMSG and the APPLMSG macro with 
> token replacement, enumerated messages, clear codes in the handling. 
> Maybe there is such, in which case my little "xmitmsgx" project might 
> reduce to simple interoperability glue code. If so, great!
>
> I WAS SHOCKED several years ago to learn that there is no equivalent 
> function in z/OS. It's an incredibly elegant way to handle 
> localization (national languages, regional dialects). This project 
> should work on MVS too; it's simple code.
>
> If you have time and inclination to try this thing (and offer feedback 
> ... or code), please holler. Thanks!
--

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

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

Re: CMS style XMITMSG for Unix and other platforms

[John McKown]

On Mon, Dec 18, 2017 at 1:25 PM, Seymour J Metz  wrote:

> My guess would be CS, but ICBW.
>

​You're right.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halz002/ip_vmcf_tnf_config.htm
​



>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Farley, Peter x23353 
> Sent: Monday, December 18, 2017 2:19 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: CMS style XMITMSG for Unix and other platforms
>
> Interesting question.  I do see a VMCF STC on our V2.1 system.  Where
> would one look to find docs on how to use it?  Comm Server docs?
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Monday, December 18, 2017 12:42 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CMS style XMITMSG for Unix and other platforms
>
> Back in the Paleolithic era IBM ported VMPC to MVS for use by TCP/IP. The
> Pascal stack has been dead for lo these many years. Is it conceivable that
> the VMCF port is still present in z/OS V2?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Farley, Peter x23353 
> Sent: Monday, December 18, 2017 11:26 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: CMS style XMITMSG for Unix and other platforms
>
> Hi Rick,
>
> I may not get to try your XMITMSG tool for a while due to other
> commitments, but the VM facility I miss the most is the SMSG / WAKEUP SMSG
> facility that permits "server" VM's to run and respond to remote requests
> from "users".  In a prior lifetime my coworkers and I used that facility to
> implement a nicely featured SCLM for an ISV.
>
> I realize that a git server is the modern incarnation of that concept and
> git is certainly a much more sophisticated SCLM tool, but it would be
> interesting anyway to have something resembling SMSG / WAKEUP SMSG
> available in z/OS.
>
> XMITMSG would be very helpful in a "disconnected server" setup for sure.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rick Troth
> Sent: Sunday, December 17, 2017 8:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CMS style XMITMSG for Unix and other platforms
>
> Aaaand ... it seems to be good enough for download: 'git clone' and then
> 'make tests'. Works.
>
> https://secure-web.cisco.com/1569EauQyiUBk0UI-kLr73Tuu_
> q0uGgwUC6o6G54m_hi6OGCs-qYYVSjKoSYKQD3QMn0V9vZwOa15GRK
> HwA2fN40NR5koQvP4FdEKHWoseYx0nPtvqhpiR0L8aE3PXDqQbY5FdCi5PbaxahZj6M0Li6U_
> CYMp41DxVmn6uoGC3SPca3uHccgCC-0NtjE3c7z_Lf2H-zkTXTnQSupTuHh-
> qigFpGQjwNzZ1sjyeAZh0iqsDvwqv_YVQ14wI_GWMf_pC6c9nQkldJQ9vFcEzcHKvVxDH0nvB
> 1ZiS8MWVUv-19t9u2TA1vZXHkS8PYNwQkPMIIC8p03BvI5LR2JoskT4jT3U-7WtZI-
> m0AGAlBRiupDN4zUWLuTTZRAESLyQ-dLRQ5M9NDoluzk5ib5Ip8N-
> HJEOj4wSaS6hjT7D4ihrgL2-YmvPw0IF5TqUOltrc3k-/https%3A%
> 2F%2Fgithub.com%2Ftrothr%2Fxmitmsgx
>
>
> You can also find it on Casita.Net:
>
> http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.0.17.tar.gz
>
>
> I'd like to hear back from someone trying it on USS. Should work fine with
> batch or TSO too when using flat filenames.
> Realy I'd like to hear back from *anyone* (using it on, e.g., AIX or Linux
> or whatever).
>
> -- R; <><
>
>
> On 12/11/17 09:34, Rick Troth wrote:
> > friends --
> >
> > VM/CMS has a wonderful utility driven by 'XMITMSG' (the command) and
> > by APPLMSG (the macro). If you're a VMer, you know about it. If you're
> > a VSE or MVS person, maybe not. It's good stuff. For (at least) the
> > second time, I started putting together an XMITMSG work-alike for Unix
> > (POSIX, including Linux). Anyone else interested in this? If so,
> > please let me know.
> >
> > There are language libraries and message handlers in Unix land. I have
> > yet to find one that works like XMITMSG and the APPLMSG macro with
> > token replacement, enumerated messages, clear codes in the handling.
> > Maybe there is such, in which case my little "xmitmsgx" project might
> > reduce to simple interoperability glue code. If so, great!
> >
> > I WAS SHOCKED several years ago to learn that there is no equivalent
> > function in z/OS. It's an incredibly elegant way to handle
> > localization (national languages, regional dialects). This project
> > should work on MVS too; it's simple code.
> >
> > If you have time and inclination to try this thing (and offer feedback
> > ... or code), please holler. Thanks!
> --
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> 

Re: ES/9000 Console Cable

[William Donzelli]

I do not think they called them HMCs back during the ES/9000 era (at
least for the little ones), just "Processor Console".

--
Will

On Mon, Dec 18, 2017 at 2:20 PM, Carmen Vitullo  wrote:
> HMC ?
> if you are talking master console, or system consoles, I believe it was a 
> token ring network
>
>
> http://www-01.ibm.com/support/docview.wss?uid=isg2ba4122bfe6d689198525666e005d3c9f=1
>
>
> this may help
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "William Donzelli" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Monday, December 18, 2017 1:04:24 PM
> Subject: ES/9000 Console Cable
>
> Quick question:
>
> On the small ES/9000s (9221-150), how exactly does the console cable
> connect to the processor? Parallel port from the PC (apparently S/390
> and 9370 are like this)?
>
> --
> Will
>
> --
> 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: ES/9000 Console Cable

[Carmen Vitullo]

correct, we never did, but checking the fine manual I found 


Hardware Management Console .. 2-4 



Carmen Vitullo 

- Original Message -

From: "William Donzelli"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, December 18, 2017 1:27:37 PM 
Subject: Re: ES/9000 Console Cable 

I do not think they called them HMCs back during the ES/9000 era (at 
least for the little ones), just "Processor Console". 

-- 
Will 

On Mon, Dec 18, 2017 at 2:20 PM, Carmen Vitullo  wrote: 
> HMC ? 
> if you are talking master console, or system consoles, I believe it was a 
> token ring network 
> 
> 
> http://www-01.ibm.com/support/docview.wss?uid=isg2ba4122bfe6d689198525666e005d3c9f=1
>  
> 
> 
> this may help 
> 
> 
> 
> Carmen Vitullo 
> 
> - Original Message - 
> 
> From: "William Donzelli"  
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Sent: Monday, December 18, 2017 1:04:24 PM 
> Subject: ES/9000 Console Cable 
> 
> Quick question: 
> 
> On the small ES/9000s (9221-150), how exactly does the console cable 
> connect to the processor? Parallel port from the PC (apparently S/390 
> and 9370 are like this)? 
> 
> -- 
> Will 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

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


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

Re: ShopZ 24/7? Maybe not so much....

[Jousma, David]

Nothing wrong with that.   But why?   Invariably, you'll need that one PTF that 
isn’t there

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, December 18, 2017 1:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ShopZ 24/7? Maybe not so much

**CAUTION EXTERNAL EMAIL**

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

On 12/18/2017 9:39 AM, Jousma, David wrote:
> ... from your comments, and from others seem to imply, that it also sounds 
> like you are picking/choosing what PTF's to download?   Why not 
> order/download everything available on a weekly basis?

Rather than downloading ALL, we choose to download only that which is 
recommended by IBM. What's wrong with that?

   SET BOUNDARY (GLOBAL) .
   RECEIVE ORDER(
     ORDERSERVER(ORDSRVR)
     CONTENT(RECOMMENDED)
     CLIENT(SMPCLNT)
     WAIT(NOLIMIT) /* As long as it takes */
   ) DELETEPKG .

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

--
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: ES/9000 Console Cable

[Carmen Vitullo]

HMC ? 
if you are talking master console, or system consoles, I believe it was a token 
ring network 


http://www-01.ibm.com/support/docview.wss?uid=isg2ba4122bfe6d689198525666e005d3c9f=1
 


this may help 



Carmen Vitullo 

- Original Message -

From: "William Donzelli"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, December 18, 2017 1:04:24 PM 
Subject: ES/9000 Console Cable 

Quick question: 

On the small ES/9000s (9221-150), how exactly does the console cable 
connect to the processor? Parallel port from the PC (apparently S/390 
and 9370 are like this)? 

-- 
Will 

-- 
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: CMS style XMITMSG for Unix and other platforms

[Anne & Lynn Wheeler]

sme...@gmu.edu (Seymour J Metz) writes:
> Back in the Paleolithic era IBM ported VMPC to MVS for use by
> TCP/IP. The Pascal stack has been dead for lo these many years. Is it
> conceivable that the VMCF port is still present in z/OS V2?

I've periodically commented about how how the communication group was
going to be responsible for the demise of the disk division
... communication group had corporate strategic responsibility
("stranglehold") for everything crossed datacenter walls and was
fiercely fighting off distributed computing and client/server (trying to
preserve their dumb terminal paradigm). some past posts
http://www.garlic.com/~lynn/subnetwork.html#terminal

Part of this was doing its best to prevent shipping TCP/IP. Eventually
it shipped but only got 44kbytes/sec transfer using whole 3090 cpu.  I
did the enhancements for rfc1044 and in some throughput tests at Cray
research, got mbyte/sec channel speed throughput between 4341 and Cray
using only modest amount of 4341 processor (possibly 500 times
improvement in cpu used per bytes moved) ... some past posts
http://www.garlic.com/~lynn/subnetwork.html#1044

sometime later, it was ported to MVS by emulating VM370 function on
MVS. However later, the communication group hired subcontractor to add
TCP/IP support to VTAM. His initial implementation had TCP/IP performing
much faster than LU6.2. He was told that everybody "knows" that a
"correct" TCP/IP implementation is much slower than LU6.2 and they would
only be paying for a "correct" implementation.

recent post in thread
http://www.garlic.com/~lynn/2017k.html#37 CMS style XMITMSG for Unix and other 
platforms
recent post about communication group
http://www.garlic.com/~lynn/2017k.html#34 Bad History

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: CMS style XMITMSG for Unix and other platforms

[Seymour J Metz]

My guess would be CS, but ICBW.


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


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Monday, December 18, 2017 2:19 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CMS style XMITMSG for Unix and other platforms

Interesting question.  I do see a VMCF STC on our V2.1 system.  Where would one 
look to find docs on how to use it?  Comm Server docs?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Monday, December 18, 2017 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CMS style XMITMSG for Unix and other platforms

Back in the Paleolithic era IBM ported VMPC to MVS for use by TCP/IP. The 
Pascal stack has been dead for lo these many years. Is it conceivable that the 
VMCF port is still present in z/OS V2?


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


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Monday, December 18, 2017 11:26 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CMS style XMITMSG for Unix and other platforms

Hi Rick,

I may not get to try your XMITMSG tool for a while due to other commitments, 
but the VM facility I miss the most is the SMSG / WAKEUP SMSG facility that 
permits "server" VM's to run and respond to remote requests from "users".  In a 
prior lifetime my coworkers and I used that facility to implement a nicely 
featured SCLM for an ISV.

I realize that a git server is the modern incarnation of that concept and git 
is certainly a much more sophisticated SCLM tool, but it would be interesting 
anyway to have something resembling SMSG / WAKEUP SMSG available in z/OS.

XMITMSG would be very helpful in a "disconnected server" setup for sure.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rick Troth
Sent: Sunday, December 17, 2017 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CMS style XMITMSG for Unix and other platforms

Aaaand ... it seems to be good enough for download: 'git clone' and then 'make 
tests'. Works.


https://secure-web.cisco.com/1569EauQyiUBk0UI-kLr73Tuu_q0uGgwUC6o6G54m_hi6OGCs-qYYVSjKoSYKQD3QMn0V9vZwOa15GRKHwA2fN40NR5koQvP4FdEKHWoseYx0nPtvqhpiR0L8aE3PXDqQbY5FdCi5PbaxahZj6M0Li6U_CYMp41DxVmn6uoGC3SPca3uHccgCC-0NtjE3c7z_Lf2H-zkTXTnQSupTuHh-qigFpGQjwNzZ1sjyeAZh0iqsDvwqv_YVQ14wI_GWMf_pC6c9nQkldJQ9vFcEzcHKvVxDH0nvB1ZiS8MWVUv-19t9u2TA1vZXHkS8PYNwQkPMIIC8p03BvI5LR2JoskT4jT3U-7WtZI-m0AGAlBRiupDN4zUWLuTTZRAESLyQ-dLRQ5M9NDoluzk5ib5Ip8N-HJEOj4wSaS6hjT7D4ihrgL2-YmvPw0IF5TqUOltrc3k-/https%3A%2F%2Fgithub.com%2Ftrothr%2Fxmitmsgx


You can also find it on Casita.Net:

http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.0.17.tar.gz


I'd like to hear back from someone trying it on USS. Should work fine with 
batch or TSO too when using flat filenames.
Realy I'd like to hear back from *anyone* (using it on, e.g., AIX or Linux or 
whatever).

-- R; <><


On 12/11/17 09:34, Rick Troth wrote:
> friends --
>
> VM/CMS has a wonderful utility driven by 'XMITMSG' (the command) and
> by APPLMSG (the macro). If you're a VMer, you know about it. If you're
> a VSE or MVS person, maybe not. It's good stuff. For (at least) the
> second time, I started putting together an XMITMSG work-alike for Unix
> (POSIX, including Linux). Anyone else interested in this? If so,
> please let me know.
>
> There are language libraries and message handlers in Unix land. I have
> yet to find one that works like XMITMSG and the APPLMSG macro with
> token replacement, enumerated messages, clear codes in the handling.
> Maybe there is such, in which case my little "xmitmsgx" project might
> reduce to simple interoperability glue code. If so, great!
>
> I WAS SHOCKED several years ago to learn that there is no equivalent
> function in z/OS. It's an incredibly elegant way to handle
> localization (national languages, regional dialects). This project
> should work on MVS too; it's simple code.
>
> If you have time and inclination to try this thing (and offer feedback
> ... or code), please holler. Thanks!
--

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

--
For IBM-MAIN subscribe / signoff / archive access 

Re: ShopZ 24/7? Maybe not so much....

[Paul Gilmartin]

On 2017-12-18, at 11:20:33, Ed Jaffe wrote:
> 
> Rather than downloading ALL, we choose to download only that which is 
> recommended by IBM. What's wrong with that?
> 
>   SET BOUNDARY (GLOBAL) .
>   RECEIVE ORDER(
> ORDERSERVER(ORDSRVR)
> CONTENT(RECOMMENDED)
> CLIENT(SMPCLNT)
> WAIT(NOLIMIT) /* As long as it takes */
>   ) DELETEPKG .
>  
Unless ORDER guarantees it, I'd be more comfortable with APPLY CHECK
to assure that all requisites have been RECEIVEd.

-- gil

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

Re: ShopZ 24/7? Maybe not so much....

[Ed Jaffe]

On 12/18/2017 11:20 AM, Jousma, David wrote:

Nothing wrong with that.   But why?   Invariably, you'll need that one PTF that 
isn’t there


Haven't had that happen, but if it ever does I will remember this 
conversation...



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

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

Re: ES/9000 Console Cable

[William Donzelli]

The ES/9000s predate this manual by ten or so years, so I thick quite
a lot changed in that time.

--
Will

On Mon, Dec 18, 2017 at 2:37 PM, Carmen Vitullo  wrote:
> correct, we never did, but checking the fine manual I found
>
>
> Hardware Management Console .. 2-4
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "William Donzelli" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Monday, December 18, 2017 1:27:37 PM
> Subject: Re: ES/9000 Console Cable
>
> I do not think they called them HMCs back during the ES/9000 era (at
> least for the little ones), just "Processor Console".
>
> --
> Will
>
> On Mon, Dec 18, 2017 at 2:20 PM, Carmen Vitullo  wrote:
>> HMC ?
>> if you are talking master console, or system consoles, I believe it was a 
>> token ring network
>>
>>
>> http://www-01.ibm.com/support/docview.wss?uid=isg2ba4122bfe6d689198525666e005d3c9f=1
>>
>>
>> this may help
>>
>>
>>
>> Carmen Vitullo
>>
>> - Original Message -
>>
>> From: "William Donzelli" 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Sent: Monday, December 18, 2017 1:04:24 PM
>> Subject: ES/9000 Console Cable
>>
>> Quick question:
>>
>> On the small ES/9000s (9221-150), how exactly does the console cable
>> connect to the processor? Parallel port from the PC (apparently S/390
>> and 9370 are like this)?
>>
>> --
>> Will
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Cobol upgrade 6.2 linklist

[Jesse 1 Robinson]

To clarify my post about putting a consolidated application library in 
LINKLIST. Audit did not 'force' us, they 'pressed' us. Difference is that Audit 
exhortations can be resisted if you don't mind going on the defensive all the 
way up the flagpole. In our case, this production library contained modules for 
all major applications. Update access to this library was managed by production 
control people, a segment of the Operations group. Audit felt that this was 
better control than allowing production jobs to STEPLIB to anything in the 
house. Concern in this case was not for mischief performed by AC=1 programs but 
by devious logic in unauthorized programs. Banks have to so darn careful. ;-)

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Monday, December 18, 2017 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Cobol upgrade 6.2 linklist

"He jests at scars that never felt a wound."

But it's not my dog.


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


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Saturday, December 16, 2017 1:26 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Cobol upgrade 6.2 linklist

Some folks have probably been burned by the abuse of user libraries in the 
LINKLIST and so preach fire and brimstone against it.

To others it is just "business as usual" because they have not experienced such 
abuse or its consequences.  I am one of them.

As I said, YMMV.  Each company is a mini-culture unto itself, and our beliefs 
and fears are ruled by culture and experience.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Friday, December 15, 2017 7:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

I dunno... when we migrated from VSE to z/OS in 2010 I was almost burned as a 
heretic for suggesting that user application libraries be placed in the 
linklist...

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Friday, December 15, 2017 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

Re: #3, that is not necessarily true.  Depends heavily on the shop-standard 
STEPLIB rules (use or don't use production "user library" in STEPLIB's).  As 
long as the "normal" rule is NOT to use production "user library" in STEPLIB's 
and you choose to use the "two library" approach to migration, putting the PDSE 
ahead of the PDS in the LINKLIST makes sense and does what you need it to do.

As usual, I think it is a case of YMMV depending on your shop's historical 
STEPLIB rules.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Friday, December 15, 2017 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

I am surprised no one yet as asked, is the OP referring to 1) The COBOL 
compiler library, 2) the COBOL runtime library, or 3) user libraries with COBOL 
programs.
1) Don't see any real need for this.
2) Probably already done, as the COBOL runtime library is CEE.SCEERUN
3) I've been told that "user libraries" like this should never be in the 
linklist.


From: IBM Mainframe Discussion List  on behalf of 
Jake Anderson 
Sent: Friday, December 15, 2017 5:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cobol upgrade 6.2 linklist

Hi

A general question

Do you still cobol load module in linklist post upgrade to 6.2 ?

Regards
Jake
--


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

Re: Cobol upgrade 6.2 linklist

[Farley, Peter x23353]

Like Skip, we are a financial institution with serious client responsibilities, 
and we also use a separate-from-development production control group as the 
only authorized updaters of the main application libraries.  AFAIK no auditor 
has ever complained about our controls or our procedures.

We also use several layers of approvals and reviews for all application code, 
which provides additional levers and control points to help protect against 
both accidental and intentional application shenanigans.

Shmuel is right to chide me for sounding like I was implying that nothing 
*could* happen.  I did not intend to say or imply that, as I am old and 
experienced enough to know Murphy all too well in all his various incarnations. 
 I was simply  stating that there has not (yet) been any serious incident with 
our setup and controls as they are.  Our ingrained culture of caring seriously 
and continuously about clients helps keep a person and an organization on their 
toes.

I'm not sure if we use the LNKLST APF feature that Peter Relson mentioned, but 
I would imagine we do, as I am darn sure that nothing I can do lets me run any 
authorized code anywhere on z/OS.  Our PARMLIB datasets are protected, so I 
cannot look to see if we use it or not.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, December 18, 2017 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

To clarify my post about putting a consolidated application library in 
LINKLIST. Audit did not 'force' us, they 'pressed' us. Difference is that Audit 
exhortations can be resisted if you don't mind going on the defensive all the 
way up the flagpole. In our case, this production library contained modules for 
all major applications. Update access to this library was managed by production 
control people, a segment of the Operations group. Audit felt that this was 
better control than allowing production jobs to STEPLIB to anything in the 
house. Concern in this case was not for mischief performed by AC=1 programs but 
by devious logic in unauthorized programs. Banks have to so darn careful. ;-)

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Monday, December 18, 2017 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Cobol upgrade 6.2 linklist

"He jests at scars that never felt a wound."

But it's not my dog.


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


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Saturday, December 16, 2017 1:26 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Cobol upgrade 6.2 linklist

Some folks have probably been burned by the abuse of user libraries in the 
LINKLIST and so preach fire and brimstone against it.

To others it is just "business as usual" because they have not experienced such 
abuse or its consequences.  I am one of them.

As I said, YMMV.  Each company is a mini-culture unto itself, and our beliefs 
and fears are ruled by culture and experience.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Friday, December 15, 2017 7:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

I dunno... when we migrated from VSE to z/OS in 2010 I was almost burned as a 
heretic for suggesting that user application libraries be placed in the 
linklist...

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Friday, December 15, 2017 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

Re: #3, that is not necessarily true.  Depends heavily on the shop-standard 
STEPLIB rules (use or don't use production "user library" in STEPLIB's).  As 
long as the "normal" rule is NOT to use production "user library" in STEPLIB's 
and you choose to use the "two library" approach to migration, putting the PDSE 
ahead of the PDS in the LINKLIST makes sense and does what you need it to do.

As usual, I think it is a case of YMMV depending on your shop's historical 
STEPLIB rules.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Friday, December 15, 2017 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

I am surprised no one yet as asked, is the OP referring to 1) The COBOL 
compiler library, 2) the COBOL runtime library, or 3) user libraries with 

Re: ShopZ 24/7? Maybe not so much....

[Jousma, David]

Tom,

FWIW, I agree with everything you are saying with regards to availability.   
But, from your comments, and from others seem to imply, that it also sounds 
like you are picking/choosing what PTF's to download?   Why not order/download 
everything available on a weekly basis?   Even if you don’t plan to apply it, 
at least the chances are much better you'll have the PTF you need at in that 
critical moment.  

Not preaching, just curious why folks just don’t download/receive everything on 
a scheduled basis. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Monday, December 18, 2017 11:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ShopZ 24/7? Maybe not so much

**CAUTION EXTERNAL EMAIL**

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

On 12/17/2017 12:52 PM, Tom Conley wrote:
> On 12/17/2017 9:59 AM, Pinnacle wrote:
>> Thought ShopZ was supposed to be available 24/7, but it appears to be 
>> taking the weekend off.  Been trying to get 3 PTF's for over an hour 
>> now.  Not like anybody would apply maintenance on a weekend or 
>> anything
>>
>> Regards,
>> Tom Conley
>>
> 
> 4 hours and counting
> 

Finally completed at 316 minutes, or 5 hours and 16 minutes for those of you at 
home.  Can't wait until I need maint to fix a Sev 1 and run into this.  What a 
joke.  I can run Windows update anytime I want, why the hell can't I do that 
for z/OS?  We'll bring this up at SHARE yet again, and IBM will assure us 
they're working on it, they'll point to their
99.99 uptime, and then nothing will change.  Lather, rinse, repeat.

WAKE UP IBM, THIS IS COMPLETELY UNACCEPTABLE FOR SERVICE DELIVERY!!!

Why am I so pissed?  We've been working with IBM for AT LEAST five years 
concerning 24/7 availability for both Service Delivery and IBMLink.  Yet we 
continue to have these extended outages.  No wonder people want off the 
mainframe.

Regards,
Tom Conley

--
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: ShopZ 24/7? Maybe not so much....

[Ed Jaffe]

On 12/18/2017 8:30 AM, Tom Conley wrote:
We'll bring this up at SHARE yet again, and IBM will assure us they're 
working on it, they'll point to their 99.99 uptime, and then nothing 
will change.


Funny how the downtime (.001%? Really? No! That counts only "unexpected" 
outages...) always seems to occur on the weekends when sysprogs need it 
most... :-\


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

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

Re: Bad History (was: "make" question)

[Seymour J Metz]

Keep in mind that originally POSIX and UNIX were different. IBM even documented 
the discrepancies between the two. AFAIK IEEE POSIX has been swallowed by the 
successor to X/OPEN and you now only need a single certification, but that 
wasn't the case at the time of the original MVSOE.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, December 16, 2017 11:11 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Bad History (was: "make" question)

On Sat, 16 Dec 2017 16:58:15 +0800, David Crayford wrote:
>
>... I would pick gmake 9/10 because it's pervasive and more
>portable. If you work with open source software on z/OS gmake is a must
>have.
>
I imagine:

RFE: We want UNIX.

IBM: Be more specific.

Both: (After much deliberation) Single UNIX specification.

And so it went.  There's no formal specification of GNU Linux.

Sigh.

-- 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: Cobol upgrade 6.2 linklist

[Seymour J Metz]

"He jests at scars that never felt a wound."

But it's not my dog.


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


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Saturday, December 16, 2017 1:26 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Cobol upgrade 6.2 linklist

Some folks have probably been burned by the abuse of user libraries in the 
LINKLIST and so preach fire and brimstone against it.

To others it is just "business as usual" because they have not experienced such 
abuse or its consequences.  I am one of them.

As I said, YMMV.  Each company is a mini-culture unto itself, and our beliefs 
and fears are ruled by culture and experience.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Friday, December 15, 2017 7:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

I dunno... when we migrated from VSE to z/OS in 2010 I was almost burned as a 
heretic for suggesting that user application libraries be placed in the 
linklist...

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Friday, December 15, 2017 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

Re: #3, that is not necessarily true.  Depends heavily on the shop-standard 
STEPLIB rules (use or don't use production "user library" in STEPLIB's).  As 
long as the "normal" rule is NOT to use production "user library" in STEPLIB's 
and you choose to use the "two library" approach to migration, putting the PDSE 
ahead of the PDS in the LINKLIST makes sense and does what you need it to do.

As usual, I think it is a case of YMMV depending on your shop's historical 
STEPLIB rules.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Friday, December 15, 2017 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

I am surprised no one yet as asked, is the OP referring to 1) The COBOL 
compiler library, 2) the COBOL runtime library, or 3) user libraries with COBOL 
programs.
1) Don't see any real need for this.
2) Probably already done, as the COBOL runtime library is CEE.SCEERUN
3) I've been told that "user libraries" like this should never be in the 
linklist.


From: IBM Mainframe Discussion List  on behalf of 
Jake Anderson 
Sent: Friday, December 15, 2017 5:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cobol upgrade 6.2 linklist

Hi

A general question

Do you still cobol load module in linklist post upgrade to 6.2 ?

Regards
Jake
--

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

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

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

Re: Cobol upgrade 6.2 linklist

[Seymour J Metz]

It used to be that you couldn't have PDSE in LNKLSTxx, but could add a PDSE 
with an automatic SETPROG command. I don't know whether that restriction still 
exists.

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


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Friday, December 15, 2017 1:15 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Cobol upgrade 6.2 linklist

Hum , I know COBOL object modules 5+ need to be PDS/E, but I've never knew 
about the linklist restrictions with PDS/E , so what about IBM libraries in the 
linklist from my serverpac build?
alway had in CPAC.PARMLIB and migrated forward.


SYS1.SHASLNKE



SYS1.SIEALNKE


SYS1.SIEAMIGEetc
am I taking unnecessary chances?



Carmen Vitullo

- Original Message -

From: "Lizette Koehler" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, December 15, 2017 11:47:57 AM
Subject: Re: Cobol upgrade 6.2 linklist

As you will find out. Any Cobol program compiled from the Cobol Compiler from 
5.0 up will REQUIRE PDSE for the Load lib - Object LOAD.

If you have your application batch load library in the LINKLST then you will 
need to move it into the place where you start other PDS/E Dataset in the 
Linklst.

The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do not have the 
SMSPDSx ASID available at the time the LINKLST is done. You have to build it 
after the SMSPDSx STC is up

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: Friday, December 15, 2017 5:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Cobol upgrade 6.2 linklist
>
> Hi
>
> A general question
>
> Do you still cobol load module in linklist post upgrade to 6.2 ?
>
> Regards
> Jake
>

--
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: ShopZ 24/7? Maybe not so much....

[Allan Staller]

What he said!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Monday, December 18, 2017 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ShopZ 24/7? Maybe not so much

On 12/18/2017 1:19 PM, Ed Jaffe wrote:
> On 12/18/2017 9:39 AM, Jousma, David wrote:
>> ... from your comments, and from others seem to imply, that it also
>> sounds like you are picking/choosing what PTF's to download?   Why
>> not order/download everything available on a weekly basis?
>
> Rather than downloading ALL, we choose to download only that which is
> recommended by IBM. What's wrong with that?
>
>SET BOUNDARY (GLOBAL) .
>RECEIVE ORDER(
>  ORDERSERVER(ORDSRVR)
>  CONTENT(RECOMMENDED)
>  CLIENT(SMPCLNT)
>  WAIT(NOLIMIT) /* As long as it takes */
>) DELETEPKG .
>

In my case, I was trying to get AST fixes hot off the press, with a requisite 
24-hour delay to make sure all the SOURCEIDs attached.  Yeah, that's right, the 
PTF is made available before all its SOURCEIDs have been attached (I can't make 
this "stuff" up).  I do an ALL about once a month, I may start doing it weekly. 
 But Murphy applies here.  The fix you need in a time of crisis will not be 
RECEIVEd, and ShopZ will be unavailable to download it. I've also seen ShopZ 
outages reported here at all times of the day or night, so periodically 
downloading ALL is not the answer.  IBM investing in a support structure that 
is available 24/7 is the answer.  And it's been the answer for years now.

Regards,
Tom Conley

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

::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: CMS style XMITMSG for Unix and other platforms

[Seymour J Metz]

Back in the Paleolithic era IBM ported VMPC to MVS for use by TCP/IP. The 
Pascal stack has been dead for lo these many years. Is it conceivable that the 
VMCF port is still present in z/OS V2?


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


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Monday, December 18, 2017 11:26 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CMS style XMITMSG for Unix and other platforms

Hi Rick,

I may not get to try your XMITMSG tool for a while due to other commitments, 
but the VM facility I miss the most is the SMSG / WAKEUP SMSG facility that 
permits "server" VM's to run and respond to remote requests from "users".  In a 
prior lifetime my coworkers and I used that facility to implement a nicely 
featured SCLM for an ISV.

I realize that a git server is the modern incarnation of that concept and git 
is certainly a much more sophisticated SCLM tool, but it would be interesting 
anyway to have something resembling SMSG / WAKEUP SMSG available in z/OS.

XMITMSG would be very helpful in a "disconnected server" setup for sure.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rick Troth
Sent: Sunday, December 17, 2017 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CMS style XMITMSG for Unix and other platforms

EXTERNAL: This email originated from outside of Broadridge. Do not click any 
links or open any attachments unless you trust the sender and know the content 
is safe.

Aaaand ... it seems to be good enough for download: 'git clone' and then
'make tests'. Works.


https://secure-web.cisco.com/1569EauQyiUBk0UI-kLr73Tuu_q0uGgwUC6o6G54m_hi6OGCs-qYYVSjKoSYKQD3QMn0V9vZwOa15GRKHwA2fN40NR5koQvP4FdEKHWoseYx0nPtvqhpiR0L8aE3PXDqQbY5FdCi5PbaxahZj6M0Li6U_CYMp41DxVmn6uoGC3SPca3uHccgCC-0NtjE3c7z_Lf2H-zkTXTnQSupTuHh-qigFpGQjwNzZ1sjyeAZh0iqsDvwqv_YVQ14wI_GWMf_pC6c9nQkldJQ9vFcEzcHKvVxDH0nvB1ZiS8MWVUv-19t9u2TA1vZXHkS8PYNwQkPMIIC8p03BvI5LR2JoskT4jT3U-7WtZI-m0AGAlBRiupDN4zUWLuTTZRAESLyQ-dLRQ5M9NDoluzk5ib5Ip8N-HJEOj4wSaS6hjT7D4ihrgL2-YmvPw0IF5TqUOltrc3k-/https%3A%2F%2Fgithub.com%2Ftrothr%2Fxmitmsgx


You can also find it on Casita.Net:

http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.0.17.tar.gz


I'd like to hear back from someone trying it on USS. Should work fine
with batch or TSO too when using flat filenames.
Realy I'd like to hear back from *anyone* (using it on, e.g., AIX or
Linux or whatever).

-- R; <><


On 12/11/17 09:34, Rick Troth wrote:
> friends --
>
> VM/CMS has a wonderful utility driven by 'XMITMSG' (the command) and by
> APPLMSG (the macro). If you're a VMer, you know about it. If you're a
> VSE or MVS person, maybe not. It's good stuff. For (at least) the second
> time, I started putting together an XMITMSG work-alike for Unix (POSIX,
> including Linux). Anyone else interested in this? If so, please let me
> know.
>
> There are language libraries and message handlers in Unix land. I have
> yet to find one that works like XMITMSG and the APPLMSG macro with token
> replacement, enumerated messages, clear codes in the handling. Maybe
> there is such, in which case my little "xmitmsgx" project might reduce
> to simple interoperability glue code. If so, great!
>
> I WAS SHOCKED several years ago to learn that there is no equivalent
> function in z/OS. It's an incredibly elegant way to handle localization
> (national languages, regional dialects). This project should work on MVS
> too; it's simple code.
>
> If you have time and inclination to try this thing (and offer feedback
> ... or code), please holler. Thanks!
--


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


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

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

Re: ShopZ 24/7? Maybe not so much....

[Ed Jaffe]

On 12/18/2017 9:39 AM, Jousma, David wrote:

... from your comments, and from others seem to imply, that it also sounds like 
you are picking/choosing what PTF's to download?   Why not order/download 
everything available on a weekly basis?


Rather than downloading ALL, we choose to download only that which is 
recommended by IBM. What's wrong with that?


  SET BOUNDARY (GLOBAL) .
  RECEIVE ORDER(
    ORDERSERVER(ORDSRVR)
    CONTENT(RECOMMENDED)
    CLIENT(SMPCLNT)
    WAIT(NOLIMIT) /* As long as it takes */
  ) DELETEPKG .

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

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

Re: Cobol upgrade 6.2 linklist

[Jerry Whitteridge]

The issue with PDSE in the linklist is related to any PDSE that is in the
IPL linklist gets an tag to (I think it is ) XCFAS so that if you whish to
do dynamic maintenance to a product you can take the existing library out
of the linklist, but can't rename etc. You would then need to use a new
Library name to put the product back into linklist.

If you are not in the habit of doing dynamic maintenance the PDSE in the
IPL linklist isn't an issue, and if you can use different names it's also
not an issue.


--
Jerry Whitteridge

IBM Global Services
Delivery Manager
e-Mail: jerry.whitteri...@ibm.com
Cell: 602 527 4871 < Note New Phone Number

IBM Mainframe Discussion List  wrote on
12/18/2017 11:17:01 AM:

> From: Seymour J Metz 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 12/18/2017 11:17 AM
> Subject: Re: Cobol upgrade 6.2 linklist
> Sent by: IBM Mainframe Discussion List 
>
> It used to be that you couldn't have PDSE in LNKLSTxx, but could add
> a PDSE with an automatic SETPROG command. I don't know whether that
> restriction still exists.
>
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.proofpoint.com/v2/url?
> u=http-3A__mason.gmu.edu_-7Esmetz3=DwIFAw=jf_iaSHvJObTbx-
>
siA1ZOg=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E=C2kzwWYqC2ybVmHsfpyw64D6PNfA6yu1lS3vcYix7Vo=VBOFuf9SLwZLzw4062UipuCiuQswXhRkKon3Cw5np64=

>
> 
> From: IBM Mainframe Discussion List  on
> behalf of Carmen Vitullo 
> Sent: Friday, December 15, 2017 1:15 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Cobol upgrade 6.2 linklist
>
> Hum , I know COBOL object modules 5+ need to be PDS/E, but I've
> never knew about the linklist restrictions with PDS/E , so what
> about IBM libraries in the linklist from my serverpac build?
> alway had in CPAC.PARMLIB and migrated forward.
>
>
> SYS1.SHASLNKE
>
>
>
> SYS1.SIEALNKE
>
>
> SYS1.SIEAMIGEetc
> am I taking unnecessary chances?
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Lizette Koehler" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Friday, December 15, 2017 11:47:57 AM
> Subject: Re: Cobol upgrade 6.2 linklist
>
> As you will find out. Any Cobol program compiled from the Cobol
> Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD.
>
> If you have your application batch load library in the LINKLST then
> you will need to move it into the place where you start other PDS/E
> Dataset in the Linklst.
>
> The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do
> not have the SMSPDSx ASID available at the time the LINKLST is done.
> You have to build it after the SMSPDSx STC is up
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On
> > Behalf Of Jake Anderson
> > Sent: Friday, December 15, 2017 5:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Cobol upgrade 6.2 linklist
> >
> > Hi
> >
> > A general question
> >
> > Do you still cobol load module in linklist post upgrade to 6.2 ?
> >
> > Regards
> > Jake
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Cobol upgrade 6.2 linklist

[Carmen Vitullo]

I see your points, for me, it's never been in a habit of upgrading any target 
lib's that are linklisted, did that once with some older XX products (PDS) that 
didn't act well after trying dynamically refreshing LLA and the linklist, so 
I've built my linklist lib's from my target libs, and IPL most times. 


Carmen Vitullo 

- Original Message -

From: "Jerry Whitteridge"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, December 18, 2017 12:21:55 PM 
Subject: Re: Cobol upgrade 6.2 linklist 

The issue with PDSE in the linklist is related to any PDSE that is in the 
IPL linklist gets an tag to (I think it is ) XCFAS so that if you whish to 
do dynamic maintenance to a product you can take the existing library out 
of the linklist, but can't rename etc. You would then need to use a new 
Library name to put the product back into linklist. 

If you are not in the habit of doing dynamic maintenance the PDSE in the 
IPL linklist isn't an issue, and if you can use different names it's also 
not an issue. 


-- 
Jerry Whitteridge 

IBM Global Services 
Delivery Manager 
e-Mail: jerry.whitteri...@ibm.com 
Cell: 602 527 4871 < Note New Phone Number 

IBM Mainframe Discussion List  wrote on 
12/18/2017 11:17:01 AM: 

> From: Seymour J Metz  
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Date: 12/18/2017 11:17 AM 
> Subject: Re: Cobol upgrade 6.2 linklist 
> Sent by: IBM Mainframe Discussion List  
> 
> It used to be that you couldn't have PDSE in LNKLSTxx, but could add 
> a PDSE with an automatic SETPROG command. I don't know whether that 
> restriction still exists. 
> 
> -- 
> Shmuel (Seymour J.) Metz 
> https://urldefense.proofpoint.com/v2/url? 
> u=http-3A__mason.gmu.edu_-7Esmetz3=DwIFAw=jf_iaSHvJObTbx- 
> 
siA1ZOg=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E=C2kzwWYqC2ybVmHsfpyw64D6PNfA6yu1lS3vcYix7Vo=VBOFuf9SLwZLzw4062UipuCiuQswXhRkKon3Cw5np64=
 

> 
>  
> From: IBM Mainframe Discussion List  on 
> behalf of Carmen Vitullo  
> Sent: Friday, December 15, 2017 1:15 PM 
> To: IBM-MAIN@listserv.ua.edu 
> Subject: Re: Cobol upgrade 6.2 linklist 
> 
> Hum , I know COBOL object modules 5+ need to be PDS/E, but I've 
> never knew about the linklist restrictions with PDS/E , so what 
> about IBM libraries in the linklist from my serverpac build? 
> alway had in CPAC.PARMLIB and migrated forward. 
> 
> 
> SYS1.SHASLNKE 
> 
> 
> 
> SYS1.SIEALNKE 
> 
> 
> SYS1.SIEAMIGEetc 
> am I taking unnecessary chances? 
> 
> 
> 
> Carmen Vitullo 
> 
> - Original Message - 
> 
> From: "Lizette Koehler"  
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Sent: Friday, December 15, 2017 11:47:57 AM 
> Subject: Re: Cobol upgrade 6.2 linklist 
> 
> As you will find out. Any Cobol program compiled from the Cobol 
> Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD. 
> 
> If you have your application batch load library in the LINKLST then 
> you will need to move it into the place where you start other PDS/E 
> Dataset in the Linklst. 
> 
> The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do 
> not have the SMSPDSx ASID available at the time the LINKLST is done. 
> You have to build it after the SMSPDSx STC is up 
> 
> Lizette 
> 
> 
> > -Original Message- 
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
On 
> > Behalf Of Jake Anderson 
> > Sent: Friday, December 15, 2017 5:51 AM 
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Cobol upgrade 6.2 linklist 
> > 
> > Hi 
> > 
> > A general question 
> > 
> > Do you still cobol load module in linklist post upgrade to 6.2 ? 
> > 
> > Regards 
> > Jake 
> > 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> 

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


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

Re: ShopZ 24/7? Maybe not so much....

[Jesse 1 Robinson]

This is not to excuse bad behavior, but for years IBM has recommended pulling 
all available fixes on a regular schedule, e.g. daily. This to guard against 
this kind of situation: needing a particular fix in a big hurry when the 
delivery mechanism is not working for whatever reason. (Do as they say, not as 
I do.) 

We have discussed ServiceLink availability with IBM at several SHARE meetings. 
Our point was that since (probably the vast majority of) customers perform 
maintenance activities on weekends, that's the worst time for ServiceLink 
maintenance. We got considerable sympathy from the folks we met with, but they 
admitted that they don't control the schedule and could only recommend. 
Meanwhile the IBM maintenance schedule seems not to have changed. Sigh. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, December 18, 2017 9:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: ShopZ 24/7? Maybe not so much

On 12/18/2017 8:30 AM, Tom Conley wrote:
> We'll bring this up at SHARE yet again, and IBM will assure us they're 
> working on it, they'll point to their 99.99 uptime, and then nothing 
> will change.

Funny how the downtime (.001%? Really? No! That counts only "unexpected" 
outages...) always seems to occur on the weekends when sysprogs need it most... 
:-\

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


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

Re: "make" question

[Seymour J Metz]

Tabs were a bloody nuisance long before 3270 displays came along; in fact, they 
may have been worse on hardcopy terminals than on 3270s.


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


From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Thursday, December 14, 2017 2:08 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: "make" question

On Thu, Dec 14, 2017 at 12:56 PM, Jack J. Woehr  wrote:

> On 12/14/2017 7:25 AM, Gord Tomlin wrote:
>
>> All the make tools share an annoying reliance on tab characters.
>
>
> This is somehow more pernicious than punch-card-column dependencies in
> traditional IBM tools? :)


​IMO, the use of tabs as a "data character" is only annoying to people
stuck on a 3270 display.  I have _no_ problems with them when I'm using ssh
to get a UNIX shell. Boiled down, I will agree that using UNIX tools in a
TSO  (3270) environment is annoying.​ Equally annoying, to me, is the
column dependencies when I editing an HLASM or COBOL program from the UNIX
shell. And don't get me going on the "vi" that IBM distributes.


> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> http://secure-web.cisco.com/1ybTM2fIPP6WIfaVgbAVnswUzPnLdlv3Q8suGEuvNuIcWmlO1FeCilZ_8AhBDR-gmcGDcWhBJEMVBPDjtPo47Ec46mMyk-AOKheGSj1zNZIOcc1PcpkdPbisMbUUwXdyxchTPLkS9938zz2xTA-atthJaQg8nrixGqy71j40crWiVHjKaJvcMhcM9azcZhOXm_krOIUa8sblenqgCAnmtqbNSt3SM6rhLSb33bqcKbth50bY0xFf6E4s7hYftAcX6Jn6IIYuYLjj2sxSYKJ4Lid-vuodLYc4D758luythtRxrb0-N0X5-cas0_7vXj6XnN4ZzfOH5RrAwzTh8V-zKkU5HwMD6yW_7sAusgAdvov4FtuFtqpTgxabUa3aMKgLc/http%3A%2F%2Fwww.well.com%2F%7Ejax
>  # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>

--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 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

ES/9000 Console Cable

[William Donzelli]

Quick question:

On the small ES/9000s (9221-150), how exactly does the console cable
connect to the processor? Parallel port from the PC (apparently S/390
and 9370 are like this)?

--
Will

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

Re: CMS style XMITMSG for Unix and other platforms

[Anne & Lynn Wheeler]

peter.far...@broadridge.com (Farley, Peter x23353) writes:
> I may not get to try your XMITMSG tool for a while due to other
> commitments, but the VM facility I miss the most is the SMSG / WAKEUP
> SMSG facility that permits "server" VM's to run and respond to remote
> requests from "users".  In a prior lifetime my coworkers and I used
> that facility to implement a nicely featured SCLM for an ISV.
>
> I realize that a git server is the modern incarnation of that concept
> and git is certainly a much more sophisticated SCLM tool, but it would
> be interesting anyway to have something resembling SMSG / WAKEUP SMSG
> available in z/OS.
>
> XMITMSG would be very helpful in a "disconnected server" setup for sure.

triva: SPM ... special message was a superset of SMSG & IUCV combined.
It was original done for CP/67 by the IBM Pisa Scientific Center ...
and ported to vm370 in POK. I included it in my internal CSC/VM system
distribution for internal datacenters and supported by internal VNET
(even included in the original version shipped to customers). Reference
in this old post
http://www.garlic.com/~lynn/2006w.html#8
and email
http://www.garlic.com/~lynn/2006w.html#email750430
more detailed description
http://www.garlic.com/~lynn/2006w.html16

I had also done autolog facility ... originally for doing automated
benchmarks
http://www.garlic.com/~lynn/submain.html#benchmark

but was included in my internal CSC/VM distribution and quickly picked
up for starting "service virtual machines" ... which could use SPM for
doing things like early "automated operator" implementations.

It was used by the author of REXX in his multi-user (client/server)
space wars implementation ... client supported 3270 display and
client/server communication was via SPM. Since VNET internal network
supported SPM ... space war players could be on the same machine or
anyplace on the internal network. One of the problems was bot players
fairly early appeared which were beating all the human players (because
they could make moves much faster). Server was then modified that
increased energy user non-linearly as interval between moves dropped
below some (human) threashold. part of old (client) MFF PLI 
http://www.garlic.com/~lynn/2005u.html#4

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: ShopZ 24/7? Maybe not so much....

[Jerry Whitteridge]

We run a nightly batch job to receive all PTF's from IBM one for each CSI.
That way as long as the Friday job ran we should have ANY PTF for that
product if we need to apply something during the Maint window. We also
include the hold data in that same job so as to catch as many PE's as we
can.


--
Jerry Whitteridge

IBM Global Services
Delivery Manager
e-Mail: jerry.whitteri...@ibm.com
Cell: 602 527 4871 < Note New Phone Number

IBM Mainframe Discussion List  wrote on
12/18/2017 10:39:24 AM:

> From: "Jousma, David" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 12/18/2017 10:40 AM
> Subject: Re: ShopZ 24/7? Maybe not so much
> Sent by: IBM Mainframe Discussion List 
>
> Tom,
>
> FWIW, I agree with everything you are saying with regards to
> availability.   But, from your comments, and from others seem to
> imply, that it also sounds like you are picking/choosing what PTF's
> to download?   Why not order/download everything available on a
> weekly basis?   Even if you don’t plan to apply it, at least the
> chances are much better you'll have the PTF you need at in that
> critical moment.
>
> Not preaching, just curious why folks just don’t download/receive
> everything on a scheduled basis.
>
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of Tom Conley
> Sent: Monday, December 18, 2017 11:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ShopZ 24/7? Maybe not so much
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> On 12/17/2017 12:52 PM, Tom Conley wrote:
> > On 12/17/2017 9:59 AM, Pinnacle wrote:
> >> Thought ShopZ was supposed to be available 24/7, but it appears to be
> >> taking the weekend off.  Been trying to get 3 PTF's for over an hour
> >> now.  Not like anybody would apply maintenance on a weekend or
> >> anything
> >>
> >> Regards,
> >> Tom Conley
> >>
> >
> > 4 hours and counting
> >
>
> Finally completed at 316 minutes, or 5 hours and 16 minutes for
> those of you at home.  Can't wait until I need maint to fix a Sev 1
> and run into this.  What a joke.  I can run Windows update anytime I
> want, why the hell can't I do that for z/OS?  We'll bring this up at
> SHARE yet again, and IBM will assure us they're working on it,
> they'll point to their
> 99.99 uptime, and then nothing will change.  Lather, rinse, repeat.
>
> WAKE UP IBM, THIS IS COMPLETELY UNACCEPTABLE FOR SERVICE DELIVERY!!!
>
> Why am I so pissed?  We've been working with IBM for AT LEAST five
> years concerning 24/7 availability for both Service Delivery and
> IBMLink.  Yet we continue to have these extended outages.  No wonder
> people want off the mainframe.
>
> Regards,
> Tom Conley
>
> --
> 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

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

Re: ShopZ 24/7? Maybe not so much....

[Tom Conley]

On 12/18/2017 1:19 PM, Ed Jaffe wrote:

On 12/18/2017 9:39 AM, Jousma, David wrote:
... from your comments, and from others seem to imply, that it also 
sounds like you are picking/choosing what PTF's to download?   Why not 
order/download everything available on a weekly basis?


Rather than downloading ALL, we choose to download only that which is 
recommended by IBM. What's wrong with that?


   SET BOUNDARY (GLOBAL) .
   RECEIVE ORDER(
     ORDERSERVER(ORDSRVR)
     CONTENT(RECOMMENDED)
     CLIENT(SMPCLNT)
     WAIT(NOLIMIT) /* As long as it takes */
   ) DELETEPKG .



In my case, I was trying to get AST fixes hot off the press, with a 
requisite 24-hour delay to make sure all the SOURCEIDs attached.  Yeah, 
that's right, the PTF is made available before all its SOURCEIDs have 
been attached (I can't make this "stuff" up).  I do an ALL about once a 
month, I may start doing it weekly.  But Murphy applies here.  The fix 
you need in a time of crisis will not be RECEIVEd, and ShopZ will be 
unavailable to download it. I've also seen ShopZ outages reported here 
at all times of the day or night, so periodically downloading ALL is not 
the answer.  IBM investing in a support structure that is available 24/7 
is the answer.  And it's been the answer for years now.


Regards,
Tom Conley

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

Re: ShopZ 24/7? Maybe not so much....

[Clark Morris]

[Default] On 18 Dec 2017 10:40:41 -0800, in bit.listserv.ibm-main
jesse1.robin...@sce.com (Jesse 1 Robinson) wrote:

>This is not to excuse bad behavior, but for years IBM has recommended pulling 
>all available fixes on a regular schedule, e.g. daily. This to guard against 
>this kind of situation: needing a particular fix in a big hurry when the 
>delivery mechanism is not working for whatever reason. (Do as they say, not as 
>I do.) 
>
>We have discussed ServiceLink availability with IBM at several SHARE meetings. 
>Our point was that since (probably the vast majority of) customers perform 
>maintenance activities on weekends, that's the worst time for ServiceLink 
>maintenance. We got considerable sympathy from the folks we met with, but they 
>admitted that they don't control the schedule and could only recommend. 
>Meanwhile the IBM maintenance schedule seems not to have changed. Sigh. 
>
Who does control the schedule and why can;t customers contact THAT
department?  Could the shareholders among us make a stink by asking
for a proxy vote on the issue (I would be willing to sign it with my
small number of shares) and if anyone lives close to the next annual
meeting (I'm in Nova Scotia) maybe he or she could raise the question
there.

Clark Morris
>.
>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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Ed Jaffe
>Sent: Monday, December 18, 2017 9:31 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: ShopZ 24/7? Maybe not so much
>
>On 12/18/2017 8:30 AM, Tom Conley wrote:
>> We'll bring this up at SHARE yet again, and IBM will assure us they're 
>> working on it, they'll point to their 99.99 uptime, and then nothing 
>> will change.
>
>Funny how the downtime (.001%? Really? No! That counts only "unexpected" 
>outages...) always seems to occur on the weekends when sysprogs need it 
>most... :-\

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

Are levels of control one reason for cloud movement was Re: Cobol upgrade 6.2 linklist

[Clark Morris]

[Default] On 18 Dec 2017 14:11:34 -0800, in bit.listserv.ibm-main
peter.far...@broadridge.com (Farley, Peter x23353) wrote:

>Like Skip, we are a financial institution with serious client 
>responsibilities, and we also use a separate-from-development production 
>control group as the only authorized updaters of the main application 
>libraries.  AFAIK no auditor has ever complained about our controls or our 
>procedures.
>
>We also use several layers of approvals and reviews for all application code, 
>which provides additional levers and control points to help protect against 
>both accidental and intentional application shenanigans.

Do those levels of control encourage people to move applications to
other platforms or the cloud?

Clark Morris
>
>Shmuel is right to chide me for sounding like I was implying that nothing 
>*could* happen.  I did not intend to say or imply that, as I am old and 
>experienced enough to know Murphy all too well in all his various 
>incarnations.  I was simply  stating that there has not (yet) been any serious 
>incident with our setup and controls as they are.  Our ingrained culture of 
>caring seriously and continuously about clients helps keep a person and an 
>organization on their toes.
>
>I'm not sure if we use the LNKLST APF feature that Peter Relson mentioned, but 
>I would imagine we do, as I am darn sure that nothing I can do lets me run any 
>authorized code anywhere on z/OS.  Our PARMLIB datasets are protected, so I 
>cannot look to see if we use it or not.
>
>Peter
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Jesse 1 Robinson
>Sent: Monday, December 18, 2017 4:02 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Cobol upgrade 6.2 linklist
>
>To clarify my post about putting a consolidated application library in 
>LINKLIST. Audit did not 'force' us, they 'pressed' us. Difference is that 
>Audit exhortations can be resisted if you don't mind going on the defensive 
>all the way up the flagpole. In our case, this production library contained 
>modules for all major applications. Update access to this library was managed 
>by production control people, a segment of the Operations group. Audit felt 
>that this was better control than allowing production jobs to STEPLIB to 
>anything in the house. Concern in this case was not for mischief performed by 
>AC=1 programs but by devious logic in unauthorized programs. Banks have to so 
>darn careful. ;-)
>
>.
>.
>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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Seymour J Metz
>Sent: Monday, December 18, 2017 9:54 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Cobol upgrade 6.2 linklist
>
>"He jests at scars that never felt a wound."
>
>But it's not my dog.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Farley, Peter x23353 
>Sent: Saturday, December 16, 2017 1:26 AM
>To: IBM-MAIN@listserv.ua.edu
>Subject: Re: Cobol upgrade 6.2 linklist
>
>Some folks have probably been burned by the abuse of user libraries in the 
>LINKLIST and so preach fire and brimstone against it.
>
>To others it is just "business as usual" because they have not experienced 
>such abuse or its consequences.  I am one of them.
>
>As I said, YMMV.  Each company is a mini-culture unto itself, and our beliefs 
>and fears are ruled by culture and experience.
>
>Peter
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Frank Swarbrick
>Sent: Friday, December 15, 2017 7:16 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Cobol upgrade 6.2 linklist
>
>I dunno... when we migrated from VSE to z/OS in 2010 I was almost burned as a 
>heretic for suggesting that user application libraries be placed in the 
>linklist...
>
>From: IBM Mainframe Discussion List  on behalf of 
>Farley, Peter x23353 
>Sent: Friday, December 15, 2017 2:00 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Cobol upgrade 6.2 linklist
>
>Re: #3, that is not necessarily true.  Depends heavily on the shop-standard 
>STEPLIB rules (use or don't use production "user library" in STEPLIB's).  As 
>long as the "normal" rule is NOT to use production "user library" in STEPLIB's 
>and you choose to use the "two library" approach to migration, putting the 
>PDSE ahead of the PDS in the LINKLIST makes sense and does what you need it to 
>do.
>
>As usual, I think it is a case of YMMV depending on your shop's historical 
>STEPLIB rules.
>
>Peter
>
>-Original 

Re: "make" question

[Paul Gilmartin]

On Mon, 18 Dec 2017 19:47:26 -0500, Rick Troth wrote:
>
>Anyway, it's not difficult to have your makefiles fix themselves,
>converting leading 8 blanks to a tab automagically. Some of the
>makefiles in and around CMS Make do exactly that: if they land on (for
>example) Linux, they get run through 'sed' to convert leading 8 blanks
>to a single tab.
> 
Doesn't this break a macro definition or a dependency rule that happens to
start with 8 blanks?

-- gil

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

Re: ShopZ 24/7? Maybe not so much....

[Jesse 1 Robinson]

The only problem with downloading selectively is that a Recommended PTF may 
PRE(REQ) one that did not make that list. You won't know until APPLY time. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, December 18, 2017 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: ShopZ 24/7? Maybe not so much

On 12/18/2017 9:39 AM, Jousma, David wrote:
> ... from your comments, and from others seem to imply, that it also sounds 
> like you are picking/choosing what PTF's to download?   Why not 
> order/download everything available on a weekly basis?

Rather than downloading ALL, we choose to download only that which is 
recommended by IBM. What's wrong with that?

   SET BOUNDARY (GLOBAL) .
   RECEIVE ORDER(
     ORDERSERVER(ORDSRVR)
     CONTENT(RECOMMENDED)
     CLIENT(SMPCLNT)
     WAIT(NOLIMIT) /* As long as it takes */
   ) DELETEPKG .

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


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

Re: "make" question

[Rick Troth]

I cobbled up CMS Make (like three times, two being lost to former 
employers) and intentionally made "leading white space" count for 
"leading tab character". Seems to work, but I always only ever use a 
subset of full 'make' capability (on any platform).


Anyway, it's not difficult to have your makefiles fix themselves, 
converting leading 8 blanks to a tab automagically. Some of the 
makefiles in and around CMS Make do exactly that: if they land on (for 
example) Linux, they get run through 'sed' to convert leading 8 blanks 
to a single tab.


The idea is that "makefile" (or "Makefile" if you must) depends on some 
other "makefile.in", which is the master. On any platform, if 
"makefile.in" is newer, the recipe is triggered, and maybe is just ...


   sed 's#^#\t#' < makefile.in > makefile


 ... or something to that effect. (Might have to embed a real tab if 
your 'sed' is not smart enough.) Then you can edit your master rules 
files on 3270 without funky presentation and painful data entry 
incantations.


Makefile with dependencies is messy but not unheard of.

-- R; <><


On 12/18/17 13:42, Seymour J Metz wrote:

Tabs were a bloody nuisance long before 3270 displays came along; in fact, they 
may have been worse on hardcopy terminals than on 3270s.


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


From: IBM Mainframe Discussion List  on behalf of John 
McKown 
Sent: Thursday, December 14, 2017 2:08 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: "make" question

On Thu, Dec 14, 2017 at 12:56 PM, Jack J. Woehr  wrote:


On 12/14/2017 7:25 AM, Gord Tomlin wrote:


All the make tools share an annoying reliance on tab characters.


This is somehow more pernicious than punch-card-column dependencies in
traditional IBM tools? :)


​IMO, the use of tabs as a "data character" is only annoying to people
stuck on a 3270 display.  I have _no_ problems with them when I'm using ssh
to get a UNIX shell. Boiled down, I will agree that using UNIX tools in a
TSO  (3270) environment is annoying.​ Equally annoying, to me, is the
column dependencies when I editing an HLASM or COBOL program from the UNIX
shell. And don't get me going on the "vi" that IBM distributes.



--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
http://secure-web.cisco.com/1ybTM2fIPP6WIfaVgbAVnswUzPnLdlv3Q8suGEuvNuIcWmlO1FeCilZ_8AhBDR-gmcGDcWhBJEMVBPDjtPo47Ec46mMyk-AOKheGSj1zNZIOcc1PcpkdPbisMbUUwXdyxchTPLkS9938zz2xTA-atthJaQg8nrixGqy71j40crWiVHjKaJvcMhcM9azcZhOXm_krOIUa8sblenqgCAnmtqbNSt3SM6rhLSb33bqcKbth50bY0xFf6E4s7hYftAcX6Jn6IIYuYLjj2sxSYKJ4Lid-vuodLYc4D758luythtRxrb0-N0X5-cas0_7vXj6XnN4ZzfOH5RrAwzTh8V-zKkU5HwMD6yW_7sAusgAdvov4FtuFtqpTgxabUa3aMKgLc/http%3A%2F%2Fwww.well.com%2F%7Ejax
 # thinking, a way of skeptically interrogating the
universe
www.softwoehr.com # with a fine understanding of human fallibility. -
Carl Sagan


--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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


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