Re: Eliminating the systems programmer was Re: IBM cuts contractor billing by 15 percent (our else)

[Edward Gould]

> On Jun 22, 2017, at 6:50 PM, Clark Morris  wrote:
>> __SNIP--
> 
> If the goal was to eliminate the need for highly technical people who
> understand the platform and the tradeoffs, that is a futile goal for
> any operating system.  If the goal is to eliminate the need for
> assembler coded exits, this is more doable but customization will
> always be with us.  While there can be plenty of obscurity in
> assembler, how well documented are the SYS1.PARMLIB members and JES
> initialization decks that control how the systems operate?  These are
> just weird programming interfaces that can be every bit as cryptic.
> 
> As someone who did his last systems programming in the 1990s, I would
> hope that systems maintenance and upgrade has become a lot easier (and
> if IBM made the Knowledge Center and Shopz 24/365.24 available) and
> that less custom code is required because of all the new concerns that
> I didn't have to deal with.  The environment has become more complex
> for all of the operating systems so anything that can be eliminated is
> to the good.  There is enough to do so that automation of some of the
> grunt work is a good thing.
> 
> Clark Morris  

Clark,

The instructor just said systems programmers. I will agree with you on the 
exits and assembler though.
Having said that I just cannot see a non assembler person going through system 
dumps. The needed CB structure and to decode machine language and understand 
what each instruction is attempting to do is just impossible (to me)to expect 
of an average COBOL programmer. Also having said that as long as IBM is as 
cryptic  as some of their messages can be *AND* trying to understand in context 
what the return code is sort of indicating would be daunting to and programmer 
type, IMO. AT least they got rid of “call your local system programmer” 
explanations in the M
As long as I semi brought up SERVPAC, IBM needlessly (IMO) complicated the 
install process. In my opinion CBIPO and CBPDO were pretty much as good as it 
is going to get. IBM should have kept the level of the base better up to date, 
was the only issue I had. It would have cut down on the Apply’s.
Yes there are pluses for sevrpac but you stilll need to know a bit about SMPE. 
Given that SMPE is the standard for installation of maintenance I really don’t 
see SERVPAC being all that helpful. I know when I tried a couple of SERVPACs 
they were ugly and could be screwed up easily. The German support was less than 
typical IBM support.
I got the feeling that (at least according to IBM) that customers complained 
about the cost of system programmers.
Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BMC acquiring CA?

[Steve Smith]

Let's say company B has a history of being managed by smart technically
savvy people who developed their own software.  Let's also say company C
has a history of being a cash mill that just buys other companies, strips
the technical staff to the bone marrow, and milks the maintenance and
licensing revenue.  Perhaps B sees opportunities to consolidate some of the
many duplicate and redundant products of C (and with B's own), and use
their technical expertise to greatly expand their market with a relatively
modest increase in costs.

Just some hypothetical musings... any resemblance to any actual company is
purely coincidental.

sas

On Thu, Jun 22, 2017 at 10:35 PM, Peter  wrote:

> Both the ISV do have some similar products. In what way it is going to be
> an win-win situation
>
> On Jun 23, 2017 4:03 AM, "Clark Morris"  wrote:
>
> > [Default] On 22 Jun 2017 09:05:37 -0700, in bit.listserv.ibm-main
> > pinnc...@rochester.rr.com (Tom Conley) wrote:
> >
> > >On 6/22/2017 11:30 AM, Phil Smith wrote:
> > >> John McKown wrote:
> > >>> https://www.channele2e.com/news/bmc-acquiring-ca-inc-going-private/
> > >>
> > >> If this goes through, I think we'll have to admit that antitrust is
> > dead. Remember that DOJ examined the CA-Sterling deal way back in 2000
> for
> > antitrust, but let it go through. 17 years later, there are many fewer
> > players...
> > >> --
> > >>
> > >
> > >With the current administration and DOJ, you-know-what through a goose,
> > >which is bad for all of us.
> >
> > Given the total size of the market I would say it is almost
> > inevitable.  The number of mainframe shops probably is continuing to
> > decline.  Millions of lines of COBOL code have been turfed in favor of
> > SAP and its competitors.  In recent decades, IBM has not been that
> > interested in the small mainframe shop even though these can grow into
> > being big mainframe shops.  The market for ISVs is shrinking.
> >
> > Clark Morris
> > >
> > >--
> > >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
>



-- 
sas

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

Re: BMC acquiring CA?

[Phil Smith]

Peter wrote:
>Both the ISV do have some similar products. In what way it is going to be
>an win-win situation

That hasn't stopped anyone before - CA bought both ACF2 and TSS, after all. But 
yeah, it'll be interesting: BMC Unload Plus and CA FU, for one. Thing is, those 
products can likely be converged: given some sort of job converter (if that's 
even really necessary), they can push customers to one or the other. Plus 
they're utilities, so no end-user visibility.

Not so much with ACF2/TSS, whose philosophies are so different that converting 
would have huge and lasting impact, including on end-users. Hence their 
continued existence as discrete products.

My $0.02 ($0.03 Canadian); no warranty, express or implied, etc.

...phsiii

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

Re: BMC acquiring CA?

[Peter]

Both the ISV do have some similar products. In what way it is going to be
an win-win situation

On Jun 23, 2017 4:03 AM, "Clark Morris"  wrote:

> [Default] On 22 Jun 2017 09:05:37 -0700, in bit.listserv.ibm-main
> pinnc...@rochester.rr.com (Tom Conley) wrote:
>
> >On 6/22/2017 11:30 AM, Phil Smith wrote:
> >> John McKown wrote:
> >>> https://www.channele2e.com/news/bmc-acquiring-ca-inc-going-private/
> >>
> >> If this goes through, I think we'll have to admit that antitrust is
> dead. Remember that DOJ examined the CA-Sterling deal way back in 2000 for
> antitrust, but let it go through. 17 years later, there are many fewer
> players...
> >> --
> >>
> >
> >With the current administration and DOJ, you-know-what through a goose,
> >which is bad for all of us.
>
> Given the total size of the market I would say it is almost
> inevitable.  The number of mainframe shops probably is continuing to
> decline.  Millions of lines of COBOL code have been turfed in favor of
> SAP and its competitors.  In recent decades, IBM has not been that
> interested in the small mainframe shop even though these can grow into
> being big mainframe shops.  The market for ISVs is shrinking.
>
> Clark Morris
> >
> >--
> >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: EBCDIC, ASCII, ugh

[Paul Gilmartin]

On Fri, 23 Jun 2017 09:57:10 +1000, Andrew Rowley wrote:

>The biggest problem I think is proving the conversion is "round trip".
>
>I would suggest doing all conversion on the mainframe, and if you need
>to be 100% sure you could add a step to do the conversion back into a
>temporary file and compare it with the original.
> 
Yes.  And SuperC may be a better tool than checksum because if the
checksum treates the data as a stream it may be oblivious to changes
in record boundaries.

>Any conversion on another platform has a significant risk that you can't
>convert the result back to the mainframe format. The risk still exists
>with the mainframe conversion, but at least you can add the comparison
>step to catch it.
> 
But the "round trip" test should include transfer to the "distributed platform"
and retrieval from it to demonstrate that those steps are valid.

And the checksums generated on the mainframe both before and after
encryption should be compared with those on the "distributed platform"
after and before decryption.  Such checksums should routinely be preserved
for possible use in troubleshooting.

-- gil

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

Re: Eliminating the systems programmer was Re: IBM cuts contractor billing by 15 percent (our else)

[Anne & Lynn Wheeler]

cfmpub...@ns.sympatico.ca (Clark Morris) writes:
> If the goal was to eliminate the need for highly technical people who
> understand the platform and the tradeoffs, that is a futile goal for
> any operating system.  If the goal is to eliminate the need for
> assembler coded exits, this is more doable but customization will
> always be with us.  While there can be plenty of obscurity in
> assembler, how well documented are the SYS1.PARMLIB members and JES
> initialization decks that control how the systems operate?  These are
> just weird programming interfaces that can be every bit as cryptic.
>
> As someone who did his last systems programming in the 1990s, I would
> hope that systems maintenance and upgrade has become a lot easier (and
> if IBM made the Knowledge Center and Shopz 24/365.24 available) and
> that less custom code is required because of all the new concerns that
> I didn't have to deal with.  The environment has become more complex
> for all of the operating systems so anything that can be eliminated is
> to the good.  There is enough to do so that automation of some of the
> grunt work is a good thing.

23Jun1969 unbundling announcement started to charge for (application)
software, SE services, etc ... however IBM managed to make the
case that kernel software should still be free
http://www.garlic.com/~lynn/submain.html#unbundle

in the 1st part of 70s, they launch the (failed) Future System effort,
completely different from 360/370 and was going to complete 360/370 ...
supposedly major motivation was to significantly increase the
complexity of processor/controller interface as countermeasure
to clone controllers.
http://www.garlic.com/~lynn/submain.html#futuresys

however, the lack of IBM 370 offerings during the FS period is credited
with giving clone processors a market foothold. the rise of clone
processors then initiates the transition to charging for kernel software
... and my resource manager is selected as guinea pig ... I get to spend
a lot of time with lawyers and business people on charging for kernel
software
http://www.garlic.com/~lynn/subtopic.html#fairshare

eventually transition to charging for all kernel software happens
in the early 80s  starting the OCO-wars ... transition
to "object code only" ... some of this shows up in the VMSHARE
archives
http://vm.marist.edu/~vmshare/

part of the motivation was source code availability contributed to
customers making source code motifications ... which contributes to
customers needing their own system programmers and also slows down
keeping up with the latest system releases (cutting into budget that
could be spent with IBM).

this period in the first part of the 80s also saw many customers buying
4300s (in some cases ordering hundreds at a time) for placing out in
departmental areas (sort of leading wave of distributed computing
tsunami).  Initially MVS was locked out of this market. The mid-range
disks were all FBA that could be deployed out in non-datacenter
environments. Eventually 3375 CKD emulation on 3370 FBA came out ... but
that didn't significantly help. Turns out these large deparmental
deployments were looking at large tens of systems per staff member
... while MVS systems were frequently measured in tens of staff members
per MVS system (if MVS was going to play in that market, it had to
significantly lower skill requirements)
http://www.garlic.com/~lynn/submain.html#dasd

trivia: some old 4300 email from the period
http://www.garlic.com/~lynn/lhwemail.html#43xx

other trivia: TYMSHARE started offering is CMS-based online computer
conferencing free to SHARE as VmSHARE in AUG1976.

-- 
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: EBCDIC, ASCII, ugh

[Andrew Rowley]

The biggest problem I think is proving the conversion is "round trip".

I would suggest doing all conversion on the mainframe, and if you need 
to be 100% sure you could add a step to do the conversion back into a 
temporary file and compare it with the original.


Any conversion on another platform has a significant risk that you can't 
convert the result back to the mainframe format. The risk still exists 
with the mainframe conversion, but at least you can add the comparison 
step to catch it.


--
Andrew Rowley
Black Hill Software
+61 413 302 386

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

Eliminating the systems programmer was Re: IBM cuts contractor billing by 15 percent (our else)

[Clark Morris]

[Default] On 22 Jun 2017 15:13:36 -0700, in bit.listserv.ibm-main
edgould1...@comcast.net (Edward Gould) wrote:

>> On Jun 22, 2017, at 3:07 PM, Tom Conley  wrote:
>> 
>> On 6/22/2017 3:42 PM, Edward Gould wrote:
>>> http://www.theregister.co.uk/2017/06/20/ibm_contractor_crackdown/ 
>>> 
>>> IBM's contractor crackdown continues: Survivors refusing pay cut have hours 
>>> reduced
>>> Managers told to hit budgets, even if customers bleed
>> 
>> IBM continues to devalue the systems programmer.
>
>——SNIP———
>
>I think it was around 1995 when an IBM instructor (in a SERVPAC Class no less) 
>stated that IBM’s goal was to get rid of them (sysprogs).
>I challenged him about that statement. He looked men straight in the eye and 
>said that was INDEED IBM’s goal.

If the goal was to eliminate the need for highly technical people who
understand the platform and the tradeoffs, that is a futile goal for
any operating system.  If the goal is to eliminate the need for
assembler coded exits, this is more doable but customization will
always be with us.  While there can be plenty of obscurity in
assembler, how well documented are the SYS1.PARMLIB members and JES
initialization decks that control how the systems operate?  These are
just weird programming interfaces that can be every bit as cryptic.

As someone who did his last systems programming in the 1990s, I would
hope that systems maintenance and upgrade has become a lot easier (and
if IBM made the Knowledge Center and Shopz 24/365.24 available) and
that less custom code is required because of all the new concerns that
I didn't have to deal with.  The environment has become more complex
for all of the operating systems so anything that can be eliminated is
to the good.  There is enough to do so that automation of some of the
grunt work is a good thing.

Clark Morris  
>
>Ed
>--
>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: EBCDIC, ASCII, ugh

[ste...@copper.net]

I meant for you to use one of your own windows machines. One needs to have 
control of things so that one can prove that the process works before sending 
the data to the end user (who-ever that may be).

--- frank.swarbr...@outlook.com wrote:

From: Frank Swarbrick 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] EBCDIC, ASCII, ugh
Date: Thu, 22 Jun 2017 23:15:04 +

The MD5 is used to verify that the file sent from the mainframe has the same 
data when received on the interim distributed system.  So creating the MD5 
after its already there does no good.


From: IBM Mainframe Discussion List  on behalf of 
ste...@copper.net 
Sent: Thursday, June 22, 2017 4:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EBCDIC, ASCII, ugh

--- frank.swarbr...@outlook.com wrote:

From: Frank Swarbrick 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] EBCDIC, ASCII, ugh
Date: Thu, 22 Jun 2017 22:25:21 +

This is a weird one (I think).

We have a requirement to store some information in an encrypted ASCII file 
(that is, it was ASCII prior to being encrypted) on a distributed platform over 
which we have no control.  We also have a requirement that we make sure that no 
data is lost during transmission.



Are there any (easy?) options I should consider that don't use Unix files?

Thanks, Frank

-
I would think that you could ftp the file to a Windows machine and then do the 
MD5 there. ftp the file back to z/OS in Binary mode and then encrypt it and 
send it to the end user using Binary. Then have the end user send it back via 
ftp Binary, to the z/OS system.

Now run the process backwards and you should be able to compare the original to 
the "reconstituted" file and see what is amiss if anything.

This keeps you away from *nix file systems. What the customer does is their 
problem. But, once the file is encrypted and is being treated as binary, one 
would hope that there is nothing they can do to mangle that file at this point.

However, remember Murphy's laws and understand that Murphy was an optimist. 
Meanwhile, Rod Serling still shows up in a computer here and there.

Regards,
Steve Thompson

ps. This almost sounds like a situation that is begging for an MFT system to 
deal with all of this. [Managed File Transfer]

--
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: EBCDIC, ASCII, ugh

[Frank Swarbrick]

The MD5 is used to verify that the file sent from the mainframe has the same 
data when received on the interim distributed system.  So creating the MD5 
after its already there does no good.


From: IBM Mainframe Discussion List  on behalf of 
ste...@copper.net 
Sent: Thursday, June 22, 2017 4:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EBCDIC, ASCII, ugh

--- frank.swarbr...@outlook.com wrote:

From: Frank Swarbrick 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] EBCDIC, ASCII, ugh
Date: Thu, 22 Jun 2017 22:25:21 +

This is a weird one (I think).

We have a requirement to store some information in an encrypted ASCII file 
(that is, it was ASCII prior to being encrypted) on a distributed platform over 
which we have no control.  We also have a requirement that we make sure that no 
data is lost during transmission.



Are there any (easy?) options I should consider that don't use Unix files?

Thanks, Frank

-
I would think that you could ftp the file to a Windows machine and then do the 
MD5 there. ftp the file back to z/OS in Binary mode and then encrypt it and 
send it to the end user using Binary. Then have the end user send it back via 
ftp Binary, to the z/OS system.

Now run the process backwards and you should be able to compare the original to 
the "reconstituted" file and see what is amiss if anything.

This keeps you away from *nix file systems. What the customer does is their 
problem. But, once the file is encrypted and is being treated as binary, one 
would hope that there is nothing they can do to mangle that file at this point.

However, remember Murphy's laws and understand that Murphy was an optimist. 
Meanwhile, Rod Serling still shows up in a computer here and there.

Regards,
Steve Thompson

ps. This almost sounds like a situation that is begging for an MFT system to 
deal with all of this. [Managed File Transfer]

--
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: EBCDIC, ASCII, ugh

[Frank Swarbrick]

Apparently the requirement is that it be readable, when decrypted, on an ASCII 
platform.  (I don't make the rules!)


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Thursday, June 22, 2017 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EBCDIC, ASCII, ugh

I would eliminate the middle man in a different way. If this is mainframe data 
intended to be used only on mainframe, then why convert it to/from ASCII at 
all? Couldn't you FTP it as binary; store it; retrieve it; and FTP it back to 
mainframe as binary? What is to be gained by the dual conversion process?

.
.
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 retired mainframer
Sent: Thursday, June 22, 2017 3:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: EBCDIC, ASCII, ugh

Why not eliminate the middle man and convert the EBCDIC data line by line to 
ASCII (ftp can; so can a simple assembler program using TR instruction), add 
line delimiters, encrypt, create MD5, and transmit in binary.  Receiver can 
verify MD5 to confirm no data lost.

For the reverse trip, receive encrypted file, verify MD5, decrypt, find a line 
delimiter, convert line from ASCII to EBCDIC, find next delimiter, ...

Why the restriction against Unix files (I hate Unix but there are times when it 
is just the simplest method)?  If you ftp EBCDIC to Unix with conversion, ftp 
will insert line delimiters for you?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Frank Swarbrick
> Sent: Thursday, June 22, 2017 3:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EBCDIC, ASCII, ugh
>
> This is a weird one (I think).
>
> We have a requirement to store some information in an encrypted ASCII
> file
(that is, it was
> ASCII prior to being encrypted) on a distributed platform over which
> we
have no control.
> We also have a requirement that we make sure that no data is lost
> during
transmission.
>
> Currently we are creating this as an EBCDIC z/OS PS file.  We also
> have a
process that
> reads in the file and creates an MD5 hash value based on it.  Both the
data file and the MD5
> hash "file" are transmitted using FTP binary mode to a distributed FTP
server.  A process is
> run to recalculate the MD5 hash and make sure they match.
>
> The idea at this point is that a process run on the distributed side
> will
convert the file from
> EBCDIC to ASCII, adding ASCII line delimiters (based on outside
> knowledge
regarding
> the fixed length of the records in the file).  This would then be
encrypted and then
> transmitted to the final destination (in binary mode, I hope!!).
>
> That's had enough.  What's worse is that we need to be able to prove
> we
can receive the file
> back on the mainframe and 'import' it back to the original data structure.
The thought (not
> mine!) at this point is that the distributed platform will 1) retrieve
> the
file; 2) decrypt the
> file, and 3) send it back to the mainframe using FTP binary mode.  Of
course that means it's
> now in ASCII, with ASCII delimiters, on the mainframe.  We then need
> to
convert it back
> to EBCDIC so that we can load it back to the source data structures.
>
> I have not yet tried anything.  One thing I am wondering is if it
> might
make sense to place
> the ASCII file in a z/OS Unix file that is defined as being ASCII.  If
> I
copy that to an MVS
> PS dataset will it convert automatically from ASCII to EBCDIC?  Maybe not.
If I copy it
> from a Unix "ASCII" file to a Unix "EBCDIC" file will it convert it?
>
> The problem with either one of these, assuming they'd even work, is
> that
we currently have
> NO use of z/OS Unix for our business applications.  Our systems group
> uses
it when they
> have no alternative, but not beyond that as far as I am aware.
>
> If we do go forward using the Unix file system it seems like we
> probably
can greatly
> simplify the process by actually writing the original file directly to
> it
a Unix ASCII file with
> appropriate delimiters.  We could then do the MD5 has on that and send
> it
to our
> distributed FTP server in binary mode.  All they would have to do is
encrypt it and send it
> on.
>
> Are there any (easy?) options I should consider that don't use Unix files?


--
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: EBCDIC, ASCII, ugh

[Paul Gilmartin]

On Thu, 22 Jun 2017 22:25:21 +, Frank Swarbrick wrote:

>This is a weird one (I think).
>
EBCDIC.  Ugh!

>We have a requirement to store some information in an encrypted ASCII file 
>(that is, it was ASCII prior to being encrypted) on a distributed platform 
>over which we have no control.  We also have a requirement that we make sure 
>that no data is lost during transmission.
>
If your file is partially binary (ontains nondisplayable EBCDIC characters -- 
ISPF
Edit/View will alert you to this) you're probably SOL.

A couple useful tools:

o /bin/cp will convert an EBCDIC non-UNIX data set to/from a UNIX EBCDIC file,
  supplying UNIX line breaks.

o IEBGENER with DD FILEDATA=TExT will do much the same.

o /bin/iconv will convert between any two supported code pages, ASCII or EBCDIC.
  "iconv -l" will display a list.

o ISPF Edit/View will deal nicely with any tagged ASCII file, subject to the 
limitations
  of the terminal code page.

o After a round-trip, SuperC can verify the data integrity.  The most it can 
tell
  you about the ASCII intermediate stage is that no data were lost.

It appears that your requirements are:
o an EBCDIC PS file
o an ASCII UNIX file.

The more intermediate stages you can eliminate, the better.  It sounds as if
you would be happiest doing the most processing on the mainframe.

>Currently we are creating this as an EBCDIC z/OS PS file.  We also have a 
>process that reads in the file and creates an MD5 hash value based on it.  
>Both the data file and the MD5 hash "file" are transmitted using FTP binary 
>mode to a distributed FTP server.  A process is run to recalculate the MD5 
>hash and make sure they match.
>
>The idea at this point is that a process run on the distributed side will 
>convert the file from EBCDIC to ASCII, adding ASCII line delimiters (based on 
>outside knowledge regarding the fixed length of the records in the file).  
>This would then be encrypted and then transmitted to the final destination (in 
>binary mode, I hope!!).
>
>That's had enough.  What's worse is that we need to be able to prove we can 
>receive the file back on the mainframe and 'import' it back to the original 
>data structure.  The thought (not mine!) at this point is that the distributed 
>platform will 1) retrieve the file; 2) decrypt the file, and 3) send it back 
>to the mainframe using FTP binary mode.  Of course that means it's now in 
>ASCII, with ASCII delimiters, on the mainframe.  We then need to convert it 
>back to EBCDIC so that we can load it back to the source data structures.
>
>I have not yet tried anything.  One thing I am wondering is if it might make 
>sense to place the ASCII file in a z/OS Unix file that is defined as being 
>ASCII.  If I copy that to an MVS PS dataset will it convert automatically from 
>ASCII to EBCDIC?  Maybe not.  If I copy it from a Unix "ASCII" file to a Unix 
>"EBCDIC" file will it convert it?
>
>The problem with either one of these, assuming they'd even work, is that we 
>currently have NO use of z/OS Unix for our business applications.  Our systems 
>group uses it when they have no alternative, but not beyond that as far as I 
>am aware.
>
>If we do go forward using the Unix file system it seems like we probably can 
>greatly simplify the process by actually writing the original file directly to 
>it a Unix ASCII file with appropriate delimiters.  We could then do the MD5 
>has on that and send it to our distributed FTP server in binary mode.  All 
>they would have to do is encrypt it and send it on.
> 
Amen.  What encryption tool?  Is it available on the z?  Perhaps as an ICSF 
option?

I'd suggest supplying checksums (ICSF, again?) both encrypted and decrypted,
better to isolate failing stages in the process.

I hope Windows delimiters aren't a requirement.

>Are there any (easy?) options I should consider that don't use Unix files?
>
This souncs like asling, "Are there any (easy?) ways to travel coast-to-coast
that don't use internal combustion engines?"  Why?

-- gil

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

Re: EBCDIC, ASCII, ugh

[ste...@copper.net]

--- frank.swarbr...@outlook.com wrote:

From: Frank Swarbrick 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] EBCDIC, ASCII, ugh
Date: Thu, 22 Jun 2017 22:25:21 +

This is a weird one (I think).

We have a requirement to store some information in an encrypted ASCII file 
(that is, it was ASCII prior to being encrypted) on a distributed platform over 
which we have no control.  We also have a requirement that we make sure that no 
data is lost during transmission.



Are there any (easy?) options I should consider that don't use Unix files?

Thanks, Frank

- 
I would think that you could ftp the file to a Windows machine and then do the 
MD5 there. ftp the file back to z/OS in Binary mode and then encrypt it and 
send it to the end user using Binary. Then have the end user send it back via 
ftp Binary, to the z/OS system. 

Now run the process backwards and you should be able to compare the original to 
the "reconstituted" file and see what is amiss if anything.

This keeps you away from *nix file systems. What the customer does is their 
problem. But, once the file is encrypted and is being treated as binary, one 
would hope that there is nothing they can do to mangle that file at this point.

However, remember Murphy's laws and understand that Murphy was an optimist. 
Meanwhile, Rod Serling still shows up in a computer here and there.

Regards,
Steve Thompson

ps. This almost sounds like a situation that is begging for an MFT system to 
deal with all of this. [Managed File Transfer]

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

Re: EBCDIC, ASCII, ugh

[Jesse 1 Robinson]

I would eliminate the middle man in a different way. If this is mainframe data 
intended to be used only on mainframe, then why convert it to/from ASCII at 
all? Couldn't you FTP it as binary; store it; retrieve it; and FTP it back to 
mainframe as binary? What is to be gained by the dual conversion process? 

.
.
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 retired mainframer
Sent: Thursday, June 22, 2017 3:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: EBCDIC, ASCII, ugh

Why not eliminate the middle man and convert the EBCDIC data line by line to 
ASCII (ftp can; so can a simple assembler program using TR instruction), add 
line delimiters, encrypt, create MD5, and transmit in binary.  Receiver can 
verify MD5 to confirm no data lost.

For the reverse trip, receive encrypted file, verify MD5, decrypt, find a line 
delimiter, convert line from ASCII to EBCDIC, find next delimiter, ...

Why the restriction against Unix files (I hate Unix but there are times when it 
is just the simplest method)?  If you ftp EBCDIC to Unix with conversion, ftp 
will insert line delimiters for you?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Frank Swarbrick
> Sent: Thursday, June 22, 2017 3:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EBCDIC, ASCII, ugh
> 
> This is a weird one (I think).
> 
> We have a requirement to store some information in an encrypted ASCII 
> file
(that is, it was
> ASCII prior to being encrypted) on a distributed platform over which 
> we
have no control.
> We also have a requirement that we make sure that no data is lost 
> during
transmission.
> 
> Currently we are creating this as an EBCDIC z/OS PS file.  We also 
> have a
process that
> reads in the file and creates an MD5 hash value based on it.  Both the
data file and the MD5
> hash "file" are transmitted using FTP binary mode to a distributed FTP
server.  A process is
> run to recalculate the MD5 hash and make sure they match.
> 
> The idea at this point is that a process run on the distributed side 
> will
convert the file from
> EBCDIC to ASCII, adding ASCII line delimiters (based on outside 
> knowledge
regarding
> the fixed length of the records in the file).  This would then be
encrypted and then
> transmitted to the final destination (in binary mode, I hope!!).
> 
> That's had enough.  What's worse is that we need to be able to prove 
> we
can receive the file
> back on the mainframe and 'import' it back to the original data structure.
The thought (not
> mine!) at this point is that the distributed platform will 1) retrieve 
> the
file; 2) decrypt the
> file, and 3) send it back to the mainframe using FTP binary mode.  Of
course that means it's
> now in ASCII, with ASCII delimiters, on the mainframe.  We then need 
> to
convert it back
> to EBCDIC so that we can load it back to the source data structures.
> 
> I have not yet tried anything.  One thing I am wondering is if it 
> might
make sense to place
> the ASCII file in a z/OS Unix file that is defined as being ASCII.  If 
> I
copy that to an MVS
> PS dataset will it convert automatically from ASCII to EBCDIC?  Maybe not.
If I copy it
> from a Unix "ASCII" file to a Unix "EBCDIC" file will it convert it?
> 
> The problem with either one of these, assuming they'd even work, is 
> that
we currently have
> NO use of z/OS Unix for our business applications.  Our systems group 
> uses
it when they
> have no alternative, but not beyond that as far as I am aware.
> 
> If we do go forward using the Unix file system it seems like we 
> probably
can greatly
> simplify the process by actually writing the original file directly to 
> it
a Unix ASCII file with
> appropriate delimiters.  We could then do the MD5 has on that and send 
> it
to our
> distributed FTP server in binary mode.  All they would have to do is
encrypt it and send it
> on.
> 
> Are there any (easy?) options I should consider that don't use Unix files?


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

Re: EBCDIC, ASCII, ugh

[retired mainframer]

Why not eliminate the middle man and convert the EBCDIC data line by line to
ASCII (ftp can; so can a simple assembler program using TR instruction), add
line delimiters, encrypt, create MD5, and transmit in binary.  Receiver can
verify MD5 to confirm no data lost.

For the reverse trip, receive encrypted file, verify MD5, decrypt, find a
line delimiter, convert line from ASCII to EBCDIC, find next delimiter, ...

Why the restriction against Unix files (I hate Unix but there are times when
it is just the simplest method)?  If you ftp EBCDIC to Unix with conversion,
ftp will insert line delimiters for you?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Frank Swarbrick
> Sent: Thursday, June 22, 2017 3:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EBCDIC, ASCII, ugh
> 
> This is a weird one (I think).
> 
> We have a requirement to store some information in an encrypted ASCII file
(that is, it was
> ASCII prior to being encrypted) on a distributed platform over which we
have no control.
> We also have a requirement that we make sure that no data is lost during
transmission.
> 
> Currently we are creating this as an EBCDIC z/OS PS file.  We also have a
process that
> reads in the file and creates an MD5 hash value based on it.  Both the
data file and the MD5
> hash "file" are transmitted using FTP binary mode to a distributed FTP
server.  A process is
> run to recalculate the MD5 hash and make sure they match.
> 
> The idea at this point is that a process run on the distributed side will
convert the file from
> EBCDIC to ASCII, adding ASCII line delimiters (based on outside knowledge
regarding
> the fixed length of the records in the file).  This would then be
encrypted and then
> transmitted to the final destination (in binary mode, I hope!!).
> 
> That's had enough.  What's worse is that we need to be able to prove we
can receive the file
> back on the mainframe and 'import' it back to the original data structure.
The thought (not
> mine!) at this point is that the distributed platform will 1) retrieve the
file; 2) decrypt the
> file, and 3) send it back to the mainframe using FTP binary mode.  Of
course that means it's
> now in ASCII, with ASCII delimiters, on the mainframe.  We then need to
convert it back
> to EBCDIC so that we can load it back to the source data structures.
> 
> I have not yet tried anything.  One thing I am wondering is if it might
make sense to place
> the ASCII file in a z/OS Unix file that is defined as being ASCII.  If I
copy that to an MVS
> PS dataset will it convert automatically from ASCII to EBCDIC?  Maybe not.
If I copy it
> from a Unix "ASCII" file to a Unix "EBCDIC" file will it convert it?
> 
> The problem with either one of these, assuming they'd even work, is that
we currently have
> NO use of z/OS Unix for our business applications.  Our systems group uses
it when they
> have no alternative, but not beyond that as far as I am aware.
> 
> If we do go forward using the Unix file system it seems like we probably
can greatly
> simplify the process by actually writing the original file directly to it
a Unix ASCII file with
> appropriate delimiters.  We could then do the MD5 has on that and send it
to our
> distributed FTP server in binary mode.  All they would have to do is
encrypt it and send it
> on.
> 
> Are there any (easy?) options I should consider that don't use Unix files?

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

Re: BMC acquiring CA?

[Clark Morris]

[Default] On 22 Jun 2017 09:05:37 -0700, in bit.listserv.ibm-main
pinnc...@rochester.rr.com (Tom Conley) wrote:

>On 6/22/2017 11:30 AM, Phil Smith wrote:
>> John McKown wrote:
>>> https://www.channele2e.com/news/bmc-acquiring-ca-inc-going-private/
>> 
>> If this goes through, I think we'll have to admit that antitrust is dead. 
>> Remember that DOJ examined the CA-Sterling deal way back in 2000 for 
>> antitrust, but let it go through. 17 years later, there are many fewer 
>> players...
>> --
>> 
>
>With the current administration and DOJ, you-know-what through a goose, 
>which is bad for all of us.

Given the total size of the market I would say it is almost
inevitable.  The number of mainframe shops probably is continuing to
decline.  Millions of lines of COBOL code have been turfed in favor of
SAP and its competitors.  In recent decades, IBM has not been that
interested in the small mainframe shop even though these can grow into
being big mainframe shops.  The market for ISVs is shrinking.

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

EBCDIC, ASCII, ugh

[Frank Swarbrick]

This is a weird one (I think).

We have a requirement to store some information in an encrypted ASCII file 
(that is, it was ASCII prior to being encrypted) on a distributed platform over 
which we have no control.  We also have a requirement that we make sure that no 
data is lost during transmission.

Currently we are creating this as an EBCDIC z/OS PS file.  We also have a 
process that reads in the file and creates an MD5 hash value based on it.  Both 
the data file and the MD5 hash "file" are transmitted using FTP binary mode to 
a distributed FTP server.  A process is run to recalculate the MD5 hash and 
make sure they match.

The idea at this point is that a process run on the distributed side will 
convert the file from EBCDIC to ASCII, adding ASCII line delimiters (based on 
outside knowledge regarding the fixed length of the records in the file).  This 
would then be encrypted and then transmitted to the final destination (in 
binary mode, I hope!!).

That's had enough.  What's worse is that we need to be able to prove we can 
receive the file back on the mainframe and 'import' it back to the original 
data structure.  The thought (not mine!) at this point is that the distributed 
platform will 1) retrieve the file; 2) decrypt the file, and 3) send it back to 
the mainframe using FTP binary mode.  Of course that means it's now in ASCII, 
with ASCII delimiters, on the mainframe.  We then need to convert it back to 
EBCDIC so that we can load it back to the source data structures.

I have not yet tried anything.  One thing I am wondering is if it might make 
sense to place the ASCII file in a z/OS Unix file that is defined as being 
ASCII.  If I copy that to an MVS PS dataset will it convert automatically from 
ASCII to EBCDIC?  Maybe not.  If I copy it from a Unix "ASCII" file to a Unix 
"EBCDIC" file will it convert it?

The problem with either one of these, assuming they'd even work, is that we 
currently have NO use of z/OS Unix for our business applications.  Our systems 
group uses it when they have no alternative, but not beyond that as far as I am 
aware.

If we do go forward using the Unix file system it seems like we probably can 
greatly simplify the process by actually writing the original file directly to 
it a Unix ASCII file with appropriate delimiters.  We could then do the MD5 has 
on that and send it to our distributed FTP server in binary mode.  All they 
would have to do is encrypt it and send it on.

Are there any (easy?) options I should consider that don't use Unix files?

Thanks, Frank


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

Re: IBM cuts contractor billing by 15 percent (our else)

[Edward Gould]

> On Jun 22, 2017, at 3:07 PM, Tom Conley  wrote:
> 
> On 6/22/2017 3:42 PM, Edward Gould wrote:
>> http://www.theregister.co.uk/2017/06/20/ibm_contractor_crackdown/ 
>> 
>> IBM's contractor crackdown continues: Survivors refusing pay cut have hours 
>> reduced
>> Managers told to hit budgets, even if customers bleed
> 
> IBM continues to devalue the systems programmer.

——SNIP———

I think it was around 1995 when an IBM instructor (in a SERVPAC Class no less) 
stated that IBM’s goal was to get rid of them (sysprogs).
I challenged him about that statement. He looked men straight in the eye and 
said that was INDEED IBM’s goal.

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

Re: Output description of TSO TEST list PSW command

[ste...@copper.net]

After having used XDC in the early 90s, I can barely make TSO TEST and TSO 
[Auth] Test function today (because I have forgotten most of the commands and 
formats). I really do not want to go back to about 1989 trying to debug and 
upgrade ALC programs. In fact, it is so bad that I am willing to put in PIC3s 
and SVC 50 (documented at one time as the NOP SVC) and use IPCS to figure out 
what needs to be done in a program.

For those who need to TSO TEST, you will find it documented here: SA32-0975-01  
z/OS TSO/E Command Reference.

If you are doing testing of code that is "multi-tasking", good luck.

Regards,
Steve Thompson



--- dbc...@gmail.com wrote:

From: David Cole 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Output description of TSO TEST list PSW command
Date: Thu, 22 Jun 2017 10:22:07 -0400

People still use TSO TEST?

On Jun 22, 2017 10:18 AM, "Joseph Reichman"  wrote:

> I can't find documentation for this anywhere
>
> --
> 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: BMC acquiring CA?

[Edward Gould]

> On Jun 22, 2017, at 10:31 AM, Phil Smith  wrote:
> 
> John McKown wrote:
>> https://www.channele2e.com/news/bmc-acquiring-ca-inc-going-private/ 
>> 
> 
> If this goes through, I think we'll have to admit that antitrust is dead. 
> Remember that DOJ examined the CA-Sterling deal way back in 2000 for 
> antitrust, but let it go through. 17 years later, there are many fewer 
> players…

Political: Since Trump and Sessions are in the mix this time look for [ayment 
via backdoor from Russia.

Ed
> --
> 
> ...phsiii


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

Re: IBM cuts contractor billing by 15 percent (our else)

[Steve Beaver]

I wonder around the world, how many contractors refused the pay cut and went to 
work for the customer


Should be interesting how long IBM can hold out before they start firing 
managers and customers get most upset 

 

Also Setting up a LLC and getting liability insurance takes about a week and 
setting up a BASIC website can be done in 2 days.

 
Steve  
 

From: Edward Gould 
Date: June 22, 2017 at 14:33:31 CDT
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM cuts contractor billing by 15 percent (our else)
Reply-To: IBM Mainframe Discussion List 

http://www.theregister.co.uk/2017/06/20/ibm_contractor_crackdown/

IBM's contractor crackdown continues: Survivors refusing pay cut have hours 
reduced Managers told to hit budgets, even if customers bleed

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

Re: IBM cuts contractor billing by 15 percent (our else)

[Steve Beaver]

Should be interesting how long IBM can hold out before they start firing 
managers and customers get most upset 

 

Also Setting up a LLC and getting liability insurance takes about a week and 
setting up a BASIC website can be done in 2 days.

 

 

From: Edward Gould 
Date: June 22, 2017 at 14:33:31 CDT
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM cuts contractor billing by 15 percent (our else)
Reply-To: IBM Mainframe Discussion List 

http://www.theregister.co.uk/2017/06/20/ibm_contractor_crackdown/

IBM's contractor crackdown continues: Survivors refusing pay cut have hours 
reduced
Managers told to hit budgets, even if customers bleed


--
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: VSAM file as GDS

[Wayne Bickerdike]

Archaic but still documented

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/d4111b.htm

z/OS DFSMS Using Data Sets
SC23-6855-00

I made no assumptions about the original postIs there evidence of SMS?



On Fri, Jun 23, 2017 at 4:18 AM, Pommier, Rex 
wrote:

>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Marchant
> Sent: Thursday, June 22, 2017 12:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VSAM file as GDS
>
> On Thu, 22 Jun 2017 13:11:20 +1000, Wayne Bickerdike wrote:
>
> >Just take off the LIKE parameter. The GDG should have a model DSCB. Why
> >make things so hard?
>
> The "Model DSCB" is an uncataloged data set with the same name as the GDG,
> located on the volume that holds the catalog containing the GDG. As such,
> it is incompatible with SMS, and it cannot be used with SMS-managed data
> sets.
>
> LIKE and its cousins are the recommended way to do it with SMS.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> First of all, a caveat.  I don't like MDCBs and have been trying to
> convince my employer to get rid of them as long as I've been here.  That
> being said, we have a volume that has very little on it besides thousands
> of cataloged MDCBs without any catalogs on the volume.  The people in
> charge of maintaining JCL insist upon having them and reference them
> specifically in the JCL.
>
> Example:
>
> //PFILEDD  DSN=A.B.C.D(+1),
> // UNIT=TAPE,
> // DCB=MDCB.A.B.C.D,
> // DISP=(NEW,CATLG,DELETE)
>
> Rex
>
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is
> not the intended recipient or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any disclosure, distribution, copying, or any action taken or action
> omitted in reliance on it, is strictly prohibited and may be unlawful.  If
> you have received this communication in error, please notify us immediately
> by replying to this message and destroy the material in its entirety,
> whether in electronic or hard copy format.  Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wayne V. Bickerdike

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

Re: IBM cuts contractor billing by 15 percent (our else)

[Tom Conley]

On 6/22/2017 3:42 PM, Edward Gould wrote:

http://www.theregister.co.uk/2017/06/20/ibm_contractor_crackdown/

IBM's contractor crackdown continues: Survivors refusing pay cut have hours 
reduced
Managers told to hit budgets, even if customers bleed



IBM continues to devalue the systems programmer.

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

Re: IEAMSCHD no FRR param

[Steve Smith]

"and SDWAPARM" would be more accurate.  Thinking as a programmer, you would
presumably get it from one *or* the other.

btw, I found that the address will be a freakishly low address, something
like x'0B00'.  Do not be frightened.

sas

On Thu, Jun 22, 2017 at 9:29 AM, Greg Dyck  wrote:

> On 6/22/2017 4:17 AM, contactmura...@gmail.com wrote:
>
>> I am new to SRBs & FRRs. I have a question regarding FRR Parameter
>> address discussed over here.
>>
>> When said "If the SRB abends, its FRR receives the address of the FRR
>> parameter area in R2 (or SDWAPARM)."
>>
>> Why is it (or SDWAPARM)? That means the contents in R2 can't be trusted
>> all the times and SDWAPARM always has the correct FRR parameter address no
>> matter what is in R2?
>>
>> I am asking this question because of the below scenario.
>>
>> Suppose my SRB issues a system macro say, 'STORAGE OBTAIN' and for some
>> reason it fails inside a system program. At that time, R2 might contain
>> some ghost value. Before control reaches FRR,
>>
>> - Does the system restores the original contents of R2 that was at the
>> time of
>>entry into SRB?
>>
>> - OR in such cases R2 will be corrupted but at the entry point of FRR, the
>>SDWAPARM field anyways contains the correct address of FRRPARM.
>>
>> Can someone please help me understand this.
>>
>
> The current registers at entry to the FRR are set by RTM.  They are *not*
> the registers at the time of the error.  The registers at time of error are
> only found in the SDWA.
>
> RTM will *always* set R2 to point to the FRR 6 word parameter list
> associated with the FRR prior to calling the FRR.  The same value is also
> stored into SDWAPARM by RTM.  There is no guarantee, however, that *your*
> program will have executed long enough to fill in any data in the parameter
> list after the FRR was set.
>
> Regards,
> Greg
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

IBM cuts contractor billing by 15 percent (our else)

[Edward Gould]

http://www.theregister.co.uk/2017/06/20/ibm_contractor_crackdown/

IBM's contractor crackdown continues: Survivors refusing pay cut have hours 
reduced
Managers told to hit budgets, even if customers bleed


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

Re: PDSE dataset rename issue

[Jesse 1 Robinson]

Thanks for the display commands. But while several responders have tried to 
diagnose the nature of OP's problem, the real problem is that deleting or 
renaming a linklist data set has always been a horrible idea regardless of its 
'E-ness'. There seems to persist the illusion that modifying a linklist dataset 
out of immediate view of LLA and XCFAS will somehow fix a problem. The answer 
for all is to rebuild the linklist with a newly-named dataset or--in the case 
of nonSMS--a newly located dataset. This tech note indicates the proper action. 

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

.
.
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 Bill Allen
Sent: Thursday, June 22, 2017 6:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: PDSE dataset rename issue

Try issuing the following operator command D 
SMS,PDSE1,CONNECTIONS,DSN(SYS1.SIEALNKE) to see which address spaces are 
connected to it. I received the same error on a delete of a PDSE and it was 
being held by an Initiator. 
see http://www-01.ibm.com/support/docview.wss?uid=isg3T1012811

If possible, stop the Address Spaces. Also issue the command with just PDSE.  D 
SMS,PDSE,CONNECTIONS,DSN(SYS1.SIEALNKE). On my system, the linklsted PDSE 
displays from syslog are below. Being connected to *MASTER* is the probably the 
reason you cannot delete an IPL-time LNKLST PDSE.

D SMS,PDSE1,CONNECTIONS,DSN(SYS1.SIEALNKE)  

IEF196I IEF237I 5110 ALLOCATED TO SYS00247  
IEF196I IEF285I   SYS17173.T091258.RA000.MSTJCL00.R0113017 KEPT 
IEF196I IEF285I   VOL SER NOS= M22RS1.  
IGW051I PDSE CONNECTIONS Start of Report(SMSPDSE1)
-data set name-- -vsgt---   
SYS1.SIEALNKE01-M22RS1-00010D   
--asid-- --name-- --tcb--- -open-   
  001F   LLA  007F8680 Input
PDSE CONNECTIONS End of Report(SMSPDSE1)   

D SMS,PDSE,CONNECTIONS,DSN(SYS1.SIEALNKE)  

IGW051I PDSE CONNECTIONS Start of Report(SMSPDSE )  
 IEF196I IEF237I 5110 ALLOCATED TO SYS00248   
 IEF196I IEF285I   SYS17173.T091319.RA000.MSTJCL00.R0113108 KEPT  
 IEF196I IEF285I   VOL SER NOS= M22RS1.   
-data set name-- -vsgt---   
SYS1.SIEALNKE01-M22RS1-00010D   
--asid-- --name-- --tcb--- -open-   
  0001   *MASTER*  Input
PDSE CONNECTIONS End of Report(SMSPDSE )


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

Re: IBM customer anchor

[Gord Tomlin]

On 2017-06-22 13:04, Paul Gilmartin wrote:

Had CA squatted on their claim before IBM established a registry?


IIRC Peter Relson established the registry when he first established the 
table.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

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

Re: VSAM file as GDS

[Pommier, Rex]

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, June 22, 2017 12:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSAM file as GDS

On Thu, 22 Jun 2017 13:11:20 +1000, Wayne Bickerdike wrote:

>Just take off the LIKE parameter. The GDG should have a model DSCB. Why 
>make things so hard?

The "Model DSCB" is an uncataloged data set with the same name as the GDG, 
located on the volume that holds the catalog containing the GDG. As such, it is 
incompatible with SMS, and it cannot be used with SMS-managed data sets.

LIKE and its cousins are the recommended way to do it with SMS.

--
Tom Marchant

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


First of all, a caveat.  I don't like MDCBs and have been trying to convince my 
employer to get rid of them as long as I've been here.  That being said, we 
have a volume that has very little on it besides thousands of cataloged MDCBs 
without any catalogs on the volume.  The people in charge of maintaining JCL 
insist upon having them and reference them specifically in the JCL.  

Example:

//PFILEDD  DSN=A.B.C.D(+1),   
// UNIT=TAPE,
// DCB=MDCB.A.B.C.D,  
// DISP=(NEW,CATLG,DELETE)

Rex

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


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

Re: Output description of TSO TEST list PSW command

[Tom Marchant]

On Thu, 22 Jun 2017 12:53:31 -0400, David Cole wrote:

>All that is true; nevertheless, it was the glaring deficiencies of TEST
>TEST that exasperated me into declaring, "I can do better!"
>
>And I have.

Indeed you have.

Thank you.

-- 
Tom Marchant

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

Re: VSAM file as GDS

[Gibney, Dave]

We haven't had model DSCB's in a very long time. It doesn't take LIKE. 
A DEFAULT DATACLAS that actually  specifies very little works just fine. 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tom Marchant
> Sent: Thursday, June 22, 2017 10:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VSAM file as GDS
> 
> On Thu, 22 Jun 2017 13:11:20 +1000, Wayne Bickerdike wrote:
> 
> >Just take off the LIKE parameter. The GDG should have a model DSCB. Why
> >make things so hard?
> 
> The "Model DSCB" is an uncataloged data set with the same name as the GDG,
> located on the volume that holds the catalog containing the GDG. As such, it
> is incompatible with SMS, and it cannot be used with SMS-managed data sets.
> 
> LIKE and its cousins are the recommended way to do it with SMS.
> 
> --
> Tom Marchant
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: how to hide PS files

[Paul Gilmartin]

On Thu, 22 Jun 2017 12:10:58 -0500, John McKown  wrote:
>
>> ...  So the user transmits it to himself using FTP.
>
>​That's the hole in the sock[et].​
>
I'd imagine pounding on it with ssh (Yah, everything looks like a nail ...);
a specialized user ID on either the source or target host, whichever works
better, access limited to users in ~/.ssh/authorized_keys, with
~/.ssh/.ssh/config restricting its repertoire to the desired transfer command
and excluding general shell commands.  Perhaps RACF shoud define its shell
as /bin/false.

-- gil

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

Re: VSAM file as GDS

[Tom Marchant]

On Thu, 22 Jun 2017 13:11:20 +1000, Wayne Bickerdike wrote:

>Just take off the LIKE parameter. The GDG should have a model DSCB. Why
>make things so hard?

The "Model DSCB" is an uncataloged data set with the same name as the GDG, 
located on the volume that holds the catalog containing the GDG. As such, it is 
incompatible with SMS, and it cannot be used with SMS-managed data sets.

LIKE and its cousins are the recommended way to do it with SMS.

-- 
Tom Marchant

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

Re: EXTERNAL: Re: how to hide PS files

[Jerry Whitteridge]

FTP uses by design a NET.DATA file that can hold the information. The Net.Data 
file should have a RACF security setting that only the user can read the file 
contents. This would mean the OP needs to move to a single file per user 
instead of a shared file.

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
623 869 5523
Corporate Tieline - 85523

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, June 22, 2017 10:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: how to hide PS files

On Thu, Jun 22, 2017 at 11:17 AM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 22 Jun 2017 16:48:16 +0200, R.S. wrote:
> >
> >Maybe you can achieve your goal by using PADS - RACF feature,
> >conditional access to dataset (READ only when using program FTP).
> >
> ...  So the user transmits it to himself using FTP.
>

​That's the hole in the sock[et].​

I can envision a way to do it using PADS, but it would require the FTCHKCMD 
exit to search for and deny any request to GET or PUT to the DSN in question. 
But, seeing as how I don't want to code such a thing, nor couch somebody in how 
to do it themself, I tend to not mention it as an option.
Not that I'm consistent else I would never have said what I just did.

How would _I_ do it? "Very, very carefully" using some strange tricks with APF 
and RACF SURROGAT processing.



> -- gil
>
>

--
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

IBM drops their HADOOP for Hortonworks' bundle

[Lizette Koehler]

IBM dropped its own Hadoop distribution in favor of reselling Hortonworks'
bundle of big data technologies, a decision that reduces the number of Hadoop
vendors to four. For users of the two companies, it could mean increased access
to enterprise capabilities for managing and analyzing big data. 

https://hortonworks.com/press-releases/ibm-hortonworks-expand-partnership/


Today's business leaders demand servers designed for big data that are
optimized, secure, and adapt to changing workload requirements.
http://www-03.ibm.com/systems/power/hardware/linux-lc.html offer servers built
with open technologies and designed for mission-critical data applications.
Power Systems leverages technology from the OpenPOWER Foundation, an open
technology ecosystem that uses the IBM POWER architecture to help meet the
evolving needs of big data applications. The combination of Power Systems with
https://hortonworks.com/products/data-center/hdp/ provides users with a highly
efficient platform that provides leadership performance for big data workloads
like Hadoop and Spark.

http://www.eweek.com/big-data-and-analytics/ibm-hortonworks-team-up-to-make-data
-science-more-mainstream

The companies plan to combine the Hortonworks Data Platform (HDP) with the IBM
Data Science Experience and IBM Big SQL into new integrated solutions created to
help enterprises and other organizations better analyze and manage the growing
volume of data they're accumulated.


Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

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

Re: how to hide PS files

[John McKown]

On Thu, Jun 22, 2017 at 11:17 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 22 Jun 2017 16:48:16 +0200, R.S. wrote:
> >
> >Maybe you can achieve your goal by using PADS - RACF feature,
> >conditional access to dataset (READ only when using program FTP).
> >
> ...  So the user transmits it to himself using FTP.
>

​That's the hole in the sock[et].​

I can envision a way to do it using PADS, but it would require the FTCHKCMD
exit to search for and deny any request to GET or PUT to the DSN in
question. But, seeing as how I don't want to code such a thing, nor couch
somebody in how to do it themself, I tend to not mention it as an option.
Not that I'm consistent else I would never have said what I just did.

How would _I_ do it? "Very, very carefully" using some strange tricks with
APF and RACF SURROGAT processing.



> -- gil
>
>

-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

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: IBM customer anchor

[Paul Gilmartin]

On Thu, 22 Jun 2017 01:00:46 -0500, Brian Westerman wrote:

>I know we had to contact CA and Sterling, as well as Landmark Systems about 
>using our offset.  The only one that gave us a hard time about it was CA, who 
>told us they "had it first", and then tried both money and threats to have us 
>give it up and go back and ask for another one.  I believe our legal-eze, 
>highly professional response was something like "pound salt".
>
I assume that worked.  Good.  What was your legal ground:
o Implied warranty of merchantability?  But any clever vendor will
  expressly disclaim that "to the extent permitted by state law".
o Contract language to that effect?
o Pound salt?

Had CA squatted on their claim before IBM established a registry?

>... we decided that name/tokens were probably a better way to go ...
> 
What precludes collisions of name/tokens?  Simply bigger name space?
But remember the birthday problem -- pretty soon someone will suffer.
"com.syzygyinc.xx"?  (16 isn't enough!)

--gil

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

Re: Output description of TSO TEST list PSW command

[David Cole]

All that is true; nevertheless, it was the glaring deficiencies of TEST
TEST that exasperated me into declaring, "I can do better!"

And I have.

On Jun 22, 2017 11:21 AM, "Tony Harminc"  wrote:

> On 22 June 2017 at 10:22, David Cole  wrote:
> > People still use TSO TEST?
>
> TSO TEST is the vi of the TSO world. It's always there on any system
> at any customer site, so you can get them to do things remotely that
> don't depend on a much more advanced three letter debugger being
> installed. Knowing how it works in some detail has saved my rear more
> than once.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: how to hide PS files

[Paul Gilmartin]

On Thu, 22 Jun 2017 16:48:16 +0200, R.S. wrote:
>
>Maybe you can achieve your goal by using PADS - RACF feature,
>conditional access to dataset (READ only when using program FTP).
> 
...  So the user transmits it to himself using FTP.

-- gil

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

Re: BMC acquiring CA?

[Tom Conley]

On 6/22/2017 11:30 AM, Phil Smith wrote:

John McKown wrote:

https://www.channele2e.com/news/bmc-acquiring-ca-inc-going-private/


If this goes through, I think we'll have to admit that antitrust is dead. 
Remember that DOJ examined the CA-Sterling deal way back in 2000 for antitrust, 
but let it go through. 17 years later, there are many fewer players...
--



With the current administration and DOJ, you-know-what through a goose, 
which is bad for all of us.


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

Re: BMC acquiring CA?

[Phil Smith]

John McKown wrote:
>https://www.channele2e.com/news/bmc-acquiring-ca-inc-going-private/

If this goes through, I think we'll have to admit that antitrust is dead. 
Remember that DOJ examined the CA-Sterling deal way back in 2000 for antitrust, 
but let it go through. 17 years later, there are many fewer players...
--

...phsiii

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

Re: Output description of TSO TEST list PSW command

[Tony Harminc]

On 22 June 2017 at 10:22, David Cole  wrote:
> People still use TSO TEST?

TSO TEST is the vi of the TSO world. It's always there on any system
at any customer site, so you can get them to do things remotely that
don't depend on a much more advanced three letter debugger being
installed. Knowing how it works in some detail has saved my rear more
than once.

Tony H.

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

Re: Output description of TSO TEST list PSW command

[Elardus Engelbrecht]

David Cole wrote:

>The PSW is described in great detail in the Principles of Operation. The TSO 
>TEST doc writer's presume you know that.

Indeed.


Joseph Reichman wrote:

>> That explains usage not what the output fields describe

That is a different animal. Thanks.

Could you perhaps post that output? Perhaps some explanations can be given to 
you with references to the right documents like Principles of Operation?

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: how to hide PS files

[Carmen Vitullo]

I never liked using a PS file for passwords even though it's an easy fix, but 
you see the issues, if possible I think a Co:Z SFTP solution would work best 


Carmen 


- Original Message -

From: "Ambrose Jr"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 22, 2017 8:46:25 AM 
Subject: how to hide PS files 

HI all, 

We have a setup of sending loads to other mainframe through ftp ,we kept 
all the details (ip,username,password) on PS file FTP.XX .So far all user 
send there loads using FTP.XX . I would like to know how to hide or skip 
this FTP.XX file from user perspective.We are not in situation to inverse 
new product. Please guide 


-- 
Regards, 
Ambrose jr. 
 

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


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

Re: how to hide PS files

[Elardus Engelbrecht]

Ambrose Jr wrote:

>What is 'loads'?
>Load Modules
>What is 'there loads'? there own compiled cobol program.  (sic)

Ok, Thanks. That helps a lot. I was wondering if you meant 'their' instead of 
'there'.


>I a$$ume you want to avoid sharing that dataset. One way to do is use create 
>for each FTP user a PS dataset .FTP.XX.?

>There is common PS dataset (having userid and pass for ftp), which i don't 
>want programmers to view  though they using same file for FTP there load 
>modules.

Ok, I now understand. I certainly don't recommend sharing a PS dataset 
containing sensitive information. Rather, have your programmers use their OWN 
PS dataset containing these sensitive details.

Or see below for alternative approach.


>>If you use a dataset as input source to do your FTP, you need READ access to 
>>that dataset.?
>correct, without read access there job get failed but my

Of course, Did you considered SURROGAT Class in RACF if you _MUST_ share that 
FTP.XX? (If that FTP.XX contains sensitive data from that 'other mainframe'.)

You setup an userid for FTP purposes, give access to your shared FTP.XX to that 
id only. Give access to your programmers to SURROGAT class, something like this:

.SUBMIT and give READ access to all your programmers.

That FTP job submitted by your programmers then receives as owner the FTP id 
which then can read your shared PS dataset.

In this way your programmers can't see the contents of that [shared] PS dataset.

Just setup your job that these details are not shown on the spool!

HTH!

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: how to hide PS files

[R.S.]

It is still hard to understand. You want to send some files (load 
modules or whatever) and you keep user/password in FTP.XX dataset - yes?
And you want to keep the content of the dataset in secret. However you 
want people can use the dataset for ftp transmission.

yes?

Maybe you can achieve your goal by using PADS - RACF feature, 
conditional access to dataset (READ only when using program FTP).



--
Radoslaw Skorupka
Lodz, Poland







W dniu 2017-06-22 o 16:33, Ambrose Jr pisze:

Elardus,

What is 'loads'?
Load Modules
What is 'there loads'? there own compiled
cobol program.

I a$$ume you want to avoid sharing that dataset. One way to do is use
create for each FTP user a PS dataset .FTP.XX.?

There is common PS dataset (having userid and pass for ftp), which i don't
want programmers to view  though they using same file for FTP there load
modules.

If you use a dataset as input source to do your FTP, you need READ access
to that dataset.?

correct, without read access there job get failed but my


On Thu, Jun 22, 2017 at 7:50 PM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:


Ambrose Jr wrote:


We have a setup of sending loads to other mainframe through ftp

What is 'loads'?



we kept all the details (ip,username,password) on PS file FTP.XX . So

far all user send there loads using FTP.XX .

One or many userid(s)?

What is 'there loads'?



I would like to know how to hide or skip this FTP.XX file from user

perspective.

I a$$ume you want to avoid sharing that dataset. One way to do is use
create for each FTP user a PS dataset .FTP.XX.



We are not in situation to inverse new product.

What is 'inverse new product'?



Please guide

It is very difficult to 'guide' you if you don't state clearly what you
want.

If you use a dataset as input source to do your FTP, you need READ access
to that dataset.

Alternatively, submit that FTP job using the RACF SURROGAT profile.

Consider using SFTP or consider using Automation Software. That product
can then submit your FTP jobs on your behalf using SURROGAT RACF Class, as
long you setup your RACF dataset profiles correctly.

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






==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: Output description of TSO TEST list PSW command

[Tom Conley]

On 6/22/2017 10:24 AM, Elardus Engelbrecht wrote:

Joseph Reichman wrote:


I can't find documentation for this anywhere


It, TSO TEST LISTPSW, is documented with examples and all!

Look at, but watch the wrap of this long URL!

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjc500/ikj2l2_TEST_subcommands__overview_.htm



None of the output for any of the LIST commands is documented.  Examples 
and all for the COMMAND, but not for the OUTPUT.


OP should open a PMR and submit an RCF.  Good luck.

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: Output description of TSO TEST list PSW command

[David Cole]

The PSW is described in great detail in the Principles of Operation. The
TSO TEST doc writer's presume you know that.

On Jun 22, 2017 10:29 AM, "Joseph Reichman"  wrote:

> That explains usage not what the output fields describe
>
>
>
> > On Jun 22, 2017, at 10:25 AM, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
> >
> > Joseph Reichman wrote:
> >
> >> I can't find documentation for this anywhere
> >
> > It, TSO TEST LISTPSW, is documented with examples and all!
> >
> > Look at, but watch the wrap of this long URL!
> >
> > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.
> 0/com.ibm.zos.v2r1.ikjc500/ikj2l2_TEST_subcommands__overview_.htm
> >
> > 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
>

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

Re: how to hide PS files

[Ambrose Jr]

Elardus,

What is 'loads'?
Load Modules
What is 'there loads'? there own compiled
cobol program.

I a$$ume you want to avoid sharing that dataset. One way to do is use
create for each FTP user a PS dataset .FTP.XX.?

There is common PS dataset (having userid and pass for ftp), which i don't
want programmers to view  though they using same file for FTP there load
modules.

If you use a dataset as input source to do your FTP, you need READ access
to that dataset.?

correct, without read access there job get failed but my


On Thu, Jun 22, 2017 at 7:50 PM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Ambrose Jr wrote:
>
> >We have a setup of sending loads to other mainframe through ftp
>
> What is 'loads'?
>
>
> > we kept all the details (ip,username,password) on PS file FTP.XX . So
> far all user send there loads using FTP.XX .
>
> One or many userid(s)?
>
> What is 'there loads'?
>
>
> >I would like to know how to hide or skip this FTP.XX file from user
> perspective.
>
> I a$$ume you want to avoid sharing that dataset. One way to do is use
> create for each FTP user a PS dataset .FTP.XX.
>
>
> >We are not in situation to inverse new product.
>
> What is 'inverse new product'?
>
>
> >Please guide
>
> It is very difficult to 'guide' you if you don't state clearly what you
> want.
>
> If you use a dataset as input source to do your FTP, you need READ access
> to that dataset.
>
> Alternatively, submit that FTP job using the RACF SURROGAT profile.
>
> Consider using SFTP or consider using Automation Software. That product
> can then submit your FTP jobs on your behalf using SURROGAT RACF Class, as
> long you setup your RACF dataset profiles correctly.
>
> 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
>



-- 
Regards,

Ambrose jr.


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

Re: Output description of TSO TEST list PSW command

[Joseph Reichman]

That explains usage not what the output fields describe 



> On Jun 22, 2017, at 10:25 AM, Elardus Engelbrecht 
>  wrote:
> 
> Joseph Reichman wrote:
> 
>> I can't find documentation for this anywhere
> 
> It, TSO TEST LISTPSW, is documented with examples and all!
> 
> Look at, but watch the wrap of this long URL!
> 
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjc500/ikj2l2_TEST_subcommands__overview_.htm
>  
> 
> 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

Re: Output description of TSO TEST list PSW command

[Elardus Engelbrecht]

Joseph Reichman wrote:

>I can't find documentation for this anywhere

It, TSO TEST LISTPSW, is documented with examples and all!

Look at, but watch the wrap of this long URL!

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjc500/ikj2l2_TEST_subcommands__overview_.htm
 

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: Output description of TSO TEST list PSW command

[David Cole]

People still use TSO TEST?

On Jun 22, 2017 10:18 AM, "Joseph Reichman"  wrote:

> I can't find documentation for this anywhere
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: how to hide PS files

[Elardus Engelbrecht]

Ambrose Jr wrote:

>We have a setup of sending loads to other mainframe through ftp 

What is 'loads'?


> we kept all the details (ip,username,password) on PS file FTP.XX . So far all 
> user send there loads using FTP.XX . 

One or many userid(s)?

What is 'there loads'?


>I would like to know how to hide or skip this FTP.XX file from user 
>perspective.

I a$$ume you want to avoid sharing that dataset. One way to do is use create 
for each FTP user a PS dataset .FTP.XX. 


>We are not in situation to inverse new product. 

What is 'inverse new product'?


>Please guide

It is very difficult to 'guide' you if you don't state clearly what you want.

If you use a dataset as input source to do your FTP, you need READ access to 
that dataset.

Alternatively, submit that FTP job using the RACF SURROGAT profile.

Consider using SFTP or consider using Automation Software. That product can 
then submit your FTP jobs on your behalf using SURROGAT RACF Class, as long you 
setup your RACF dataset profiles correctly.

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

Output description of TSO TEST list PSW command

[Joseph Reichman]

I can't find documentation for this anywhere  

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

BMC acquiring CA?

[John McKown]

https://www.channele2e.com/news/bmc-acquiring-ca-inc-going-private/

-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

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

how to hide PS files

[Ambrose Jr]

HI all,

We have a setup of sending loads to other mainframe through ftp ,we kept
all the details (ip,username,password) on PS file FTP.XX .So far all user
send there loads using FTP.XX . I would like to know how to hide or skip
this FTP.XX file from user perspective.We are not in situation to inverse
new product. Please guide


-- 
Regards,
Ambrose jr.


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

Re: PDSE dataset rename issue

[Bill Allen]

Try issuing the following operator command D 
SMS,PDSE1,CONNECTIONS,DSN(SYS1.SIEALNKE) to see which address spaces are 
connected to it. I received the same error on a delete of a PDSE and it was 
being held by an Initiator. 
see http://www-01.ibm.com/support/docview.wss?uid=isg3T1012811

If possible, stop the Address Spaces. Also issue the command with just PDSE.  D 
SMS,PDSE,CONNECTIONS,DSN(SYS1.SIEALNKE). On my system, the linklsted PDSE 
displays from syslog are below. Being connected to *MASTER* is the probably the 
reason you cannot delete an IPL-time LNKLST PDSE.

D SMS,PDSE1,CONNECTIONS,DSN(SYS1.SIEALNKE)  

IEF196I IEF237I 5110 ALLOCATED TO SYS00247  
IEF196I IEF285I   SYS17173.T091258.RA000.MSTJCL00.R0113017 KEPT 
IEF196I IEF285I   VOL SER NOS= M22RS1.  
IGW051I PDSE CONNECTIONS Start of Report(SMSPDSE1)
-data set name-- -vsgt---   
SYS1.SIEALNKE01-M22RS1-00010D   
--asid-- --name-- --tcb--- -open-   
  001F   LLA  007F8680 Input
PDSE CONNECTIONS End of Report(SMSPDSE1)   

D SMS,PDSE,CONNECTIONS,DSN(SYS1.SIEALNKE)  

IGW051I PDSE CONNECTIONS Start of Report(SMSPDSE )  
 IEF196I IEF237I 5110 ALLOCATED TO SYS00248   
 IEF196I IEF285I   SYS17173.T091319.RA000.MSTJCL00.R0113108 KEPT  
 IEF196I IEF285I   VOL SER NOS= M22RS1.   
-data set name-- -vsgt---   
SYS1.SIEALNKE01-M22RS1-00010D   
--asid-- --name-- --tcb--- -open-   
  0001   *MASTER*  Input
PDSE CONNECTIONS End of Report(SMSPDSE )


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

Re: IEAMSCHD no FRR param

[Greg Dyck]

On 6/22/2017 4:17 AM, contactmura...@gmail.com wrote:

I am new to SRBs & FRRs. I have a question regarding FRR Parameter address 
discussed over here.

When said "If the SRB abends, its FRR receives the address of the FRR parameter area 
in R2 (or SDWAPARM)."

Why is it (or SDWAPARM)? That means the contents in R2 can't be trusted all the 
times and SDWAPARM always has the correct FRR parameter address no matter what 
is in R2?

I am asking this question because of the below scenario.

Suppose my SRB issues a system macro say, 'STORAGE OBTAIN' and for some  reason 
it fails inside a system program. At that time, R2 might contain some ghost 
value. Before control reaches FRR,

- Does the system restores the original contents of R2 that was at the time of
   entry into SRB?

- OR in such cases R2 will be corrupted but at the entry point of FRR, the
   SDWAPARM field anyways contains the correct address of FRRPARM.

Can someone please help me understand this.


The current registers at entry to the FRR are set by RTM.  They are 
*not* the registers at the time of the error.  The registers at time of 
error are only found in the SDWA.


RTM will *always* set R2 to point to the FRR 6 word parameter list 
associated with the FRR prior to calling the FRR.  The same value is 
also stored into SDWAPARM by RTM.  There is no guarantee, however, that 
*your* program will have executed long enough to fill in any data in the 
parameter list after the FRR was set.


Regards,
Greg

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

Re: VSAM file as GDS

[Steve Smith]

The structure of a traditional GDG catalog entry doesn't have any place for
the necessary VSAM information.  On the other hand, the new extended GDG
does.  In fact, it should be able to support GDGs of anything, including
sub-GDGs... how's that for a questionable idea?

Nevertheless, to the extent those work, it's off the reservation, and IBM
certainly would have more work to do to support them.

Btw, a GDG is a generic container... individual GDSes are not required to
all be the same type.

Model DSCBs are archaic, and I don't think they've been required for a long
time.

sas

On Wed, Jun 21, 2017 at 11:11 PM, Wayne Bickerdike 
wrote:

> Just take off the LIKE parameter. The GDG should have a model DSCB. Why
> make things so hard?
>
>
>
> On Thu, Jun 22, 2017 at 12:03 PM, Steve Beaver 
> wrote:
>
> > Was it done in the same job?
> >
> > Steve
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Frank Swarbrick
> > Sent: Wednesday, June 21, 2017 4:11 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: VSAM file as GDS
> >
> > Developer did more testing and found that even though it successfully
> > created generation 1 when an attempt was made to create an additional
> > generation it failed.  :-(
> >
> > IEF344I TESTREP STEP01 FILEOUT - ALLOCATION FAILED DUE TO DATA FACILITY
> > SYSTEM ERROR
> >
> > IGD17101I DATA SET PROD.CONNDEF.PATM.BKP.G0001V00
> >
> > NOT DEFINED BECAUSE DUPLICATE NAME EXISTS IN CATALOG
> >
> > RETURN CODE IS 8 REASON CODE IS 38 IGG0CLEH
> >
> > IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of
> > Frank Swarbrick 
> > Sent: Wednesday, June 21, 2017 2:24 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: VSAM file as GDS
> >
> > Learn something new every day.  Another developer created a GDG
> > (PROD.CONNDEF.PATM.BKP) and then a job step that has the following:
> > //STEP02   EXEC PGM=IDCAMS,COND=(4,LT)
> > //FILEIN   DD DSN=PROD.ONLINE.CONNDEF.PATM,
> > //DISP=SHR
> > //FILEOUT  DD DSN=PROD.CONNDEF.PATM.BKP(+1),
> > //LIKE=PROD.ONLINE.CONNDEF.PATM,
> > //DISP=(NEW,CATLG,DELETE)
> > //SYSINDD DSN=PROD.PARM(REPRO),
> > //DISP=SHR
> > //SYSPRINT DD SYSOUT=*
> > I though for sure this would not work, as PROD.ONLINE.CONNDEF.PATM is a
> > VSAM
> > KSDS.  But it appears it in fact did work:
> > PROD.CONNDEF.PATM.BKP
> > PROD.CONNDEF.PATM.BKP.G0001V00
> > PROD.CONNDEF.PATM.BKP.G0001V00.DATA
> > PROD.CONNDEF.PATM.BKP.G0001V00.INDEX
> >
> >
> > I'm not sure how comfortable I am with it, though.  Any harm in doing
> this?
> >
> > Frank
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email
> > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email
> > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> Wayne V. Bickerdike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: IBM customer anchor

[Brian Westerman]

I know we had to contact CA and Sterling, as well as Landmark Systems about 
using our offset.  The only one that gave us a hard time about it was CA, who 
told us they "had it first", and then tried both money and threats to have us 
give it up and go back and ask for another one.  I believe our legal-eze, 
highly professional response was something like "pound salt".

I could be missing some vendors, but I think the rest of the times we had to 
debug the problem were "normal" sites that they themselves decided the offset 
was "safe" to use.  They would just choose another "safe to use" one and 
sometimes we helped them re-write and we would never have that particular issue 
again, but it became a big enough issue over time that we decided that 
name/tokens were probably a better way to go for most of the new features we 
add and we stopped adding things to our table.  We still use it though, but I 
think the direction we are moving is to eventually eliminate it's use.

Brian

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