date:20130619

On Tue, 18 Jun 2013 16:45:09 -0700, Charles Mills wrote:

... So it would not necessarily be in great a position to steal customer data
itself, but if we were malicious, and conspired with a rogue employee, we
could perhaps jointly steal valuable data.

..., nor how to defeat our keys. ...
 
'keys' sounds a lot like backdoor or 'magic' SVC.  I.e.
anything which if a customer's rogue employee knew it could 
be used to compromise system security.

Imagine, very hypothetically, that you had no concerns for
your IP.  Then not letting the entire world see all your
source code would amount to security by obscurity.

-- gil

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

Re: Retrieving jobs of input queue

2013-06-19 Thread k Zaf

Hi all,

Thank you for your answers. Note that I would like to bypass in my REXX the
use of address ISFEXEC or ISFACT. This is because I am not using standard
TSO REXX but OPS/MVS REXX which is not supporting (yet) a host environment
to SDSF.


Kind regards


On 18 June 2013 23:35, Kirk Wolf k...@dovetail.com wrote:

 You can use the lsjes command:

 See: https://www.dovetail.com/docs/coz/dsp-ref_lsjes.html

 This could be called from REXX using bpxwunix() or the SH host command
 environment.

 Also, the fromdsn command can be used to extract spool files for a job.

 Kirk Wolf
 Dovetailed Technologies
 http://dovetail.com

 PS The Co:Z Toolkit is free to download and use under our Community
 License.
 Enterprise License and Support agreements are also available:
 http://dovetail.com/support.html

 On Tue, Jun 18, 2013 at 9:17 AM, K kzafi...@gmail.com wrote:

  Hello all
 
  Could I retrieve Jobs and their jobids of JES2 input queue though REXX
 but
  WITHOUT use of SDSF.
 
  Kind regards
  Kostas
 
  --
  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

2084-D48?

Just curious

Has anyone heard about z990 machine 2084 D48 ?
Note, there are (were) models A08, B16, C24 and D32.

IBM just announced end of service for selected machines and mentined
five models of 2084, including the D48 one.

--
Radoslaw Skorupka
Lodz, Poland

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

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Są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.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.

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

Simulate SMS SC somehow ?

2013-06-19 Thread Miklos Szigetvari


Hi

Any way to simulate the SMS storage class for NON MANAGED datasets?
(Explanation: I would need an SMS SC for PDSE data caching, but the 
volumes, with the data,  are non SMS managed currently)



--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---

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

Re: IBM commitment to academia

2013-06-19 Thread Timothy Sipples

Yes, sorry about that. Well, the problem probably got fixed ~10 years ago.
Which is better than, say, ~5 years ago.

It is my faded-memory impression that it was, as Timothy pointed
out, DEC's aggressive push of very low-cost and free stuff into
universities that both permitted and accelerated the rise of *ix
and also contributed to the decline of IBM mainframes on campus
(though that was not the only reason).

My recollection is that DEC didn't really want it that way. DEC would have
very much preferred if VMS and/or TOPS-10/20 got more popular in academia.
Sure, DEC was happier if BSD UNIX ran on their PDP or VAX hardware rather
than somebody else's hardware, but in hindsight that wasn't enough.

It's impossible to re-run history, but I suspect that if DEC didn't provide
subsidized hardware to run ATT's/BSD's operating system then there'd just
be some other subsidized hardware performing the same role. It would have
been something of early 1970s vintage that competed with the PDP-11. Maybe
something from CDC, Data General, or Honeywell/Prime. There was also a
fortuitous bit of DARPA funding aimed at Berkeley that helped UNIX at a
critical stage in its evolution.


Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF70INT format

2013-06-19 Thread Massimo Biancucci

Donald,

I use a similar formula us = trunc(smf70wat/4096).

As long as one second = 1.000.000 of us the formula seems to be the very
same  ! :D

Best regards.
Massimo Biancucci



2013/6/19 Donald Likens dlik...@infosecinc.com

 We do not have SAS (Can you believe it). My real problem is not with
 SMF70INT but with SMF70WAT (and other fields). I am now converting both of
 these fields to seconds for the equation.

 The conversion of SMF70INT is easy but I am not sure about SMF70WAT. What
 I am doing is  as follows:

 Seconds = SMF70WAT/4,096,000,000

 I think that is what the 51 bit indicates microseconds.

 Can someone please confirm this calculation or give me the correct formula?

 SMF70WAT DSCL8  CPU wait time, where bit 51 = 1 microsecond

 --
 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: RDz or RDzEnterprise developers

2013-06-19 Thread Thomas Dunlap


Graham,

The issue is not which version of RDz but rather which version of 
Windows.  Even with RDz 7.6 the COBOL compiler would not install on 
Windows 7.  IBM has not made, plus as I understand it, a COBOL compiler 
which works on Windows 7.  I am in the same position, but do have a 
System z to connect to as a test platform.


I too wish I could test locally on Windows 7.

Cheers,
Thomas Dunlap



On 6/18/2013 5:34 PM, Graham Hobbs wrote:

Hello,

I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and moved to a 
new Lenovo with Windows 7. There is no need for host connection, my development 
world is as a standalone, compile/link/run COBOL programs and COBOL/CICS 
transaction programs on the Lenovo is the critical need.

But I understand that Rational Developer for System z V8.5 does not 'do' COBOL 
on Windows 7 so am thinking my new world should be Rational Developer for 
zEnterprise V8.0.3 and would appreciate any comments/advice about that.
  
Graham Hobbs


--
___
Regards,
Thomas DunlapChief Technology Officert...@themisinc.com
Themis,  Inc.http://www.themisinc.com1 (800) 756-3000

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

Re: Retrieving jobs of input queue

2013-06-19 Thread k Zaf

Hi all

I rather try to use JES2 command  $djq,q=xeq,busy=no to find out jobs
awaiting in INPUT queue

Thanks in any case


On 19 June 2013 10:20, k Zaf kzafi...@gmail.com wrote:

 Hi all,

 Thank you for your answers. Note that I would like to bypass in my REXX
 the use of address ISFEXEC or ISFACT. This is because I am not using
 standard TSO REXX but OPS/MVS REXX which is not supporting (yet) a host
 environment to SDSF.


 Kind regards


 On 18 June 2013 23:35, Kirk Wolf k...@dovetail.com wrote:

 You can use the lsjes command:

 See: https://www.dovetail.com/docs/coz/dsp-ref_lsjes.html

 This could be called from REXX using bpxwunix() or the SH host command
 environment.

 Also, the fromdsn command can be used to extract spool files for a job.

 Kirk Wolf
 Dovetailed Technologies
 http://dovetail.com

 PS The Co:Z Toolkit is free to download and use under our Community
 License.
 Enterprise License and Support agreements are also available:
 http://dovetail.com/support.html

 On Tue, Jun 18, 2013 at 9:17 AM, K kzafi...@gmail.com wrote:

  Hello all
 
  Could I retrieve Jobs and their jobids of JES2 input queue though REXX
 but
  WITHOUT use of SDSF.
 
  Kind regards
  Kostas
 
  --
  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: Retrieving jobs of input queue

2013-06-19 Thread Itschak Mugzach

FTP with SITE filetype=JES? Console command is also an option.

ITschak


On Tue, Jun 18, 2013 at 11:35 PM, Kirk Wolf k...@dovetail.com wrote:

 You can use the lsjes command:

 See: https://www.dovetail.com/docs/coz/dsp-ref_lsjes.html

 This could be called from REXX using bpxwunix() or the SH host command
 environment.

 Also, the fromdsn command can be used to extract spool files for a job.

 Kirk Wolf
 Dovetailed Technologies
 http://dovetail.com

 PS The Co:Z Toolkit is free to download and use under our Community
 License.
 Enterprise License and Support agreements are also available:
 http://dovetail.com/support.html

 On Tue, Jun 18, 2013 at 9:17 AM, K kzafi...@gmail.com wrote:

  Hello all
 
  Could I retrieve Jobs and their jobids of JES2 input queue though REXX
 but
  WITHOUT use of SDSF.
 
  Kind regards
  Kostas
 
  --
  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: RDz or RDzEnterprise developers

2013-06-19 Thread Barry Merrill

You can use the XP Virtual Machine under Win 7 for archaic XP applications.

(I'm still running MXG Business on the DOS version of DataFlex, 
in the XP Box on Win 7 Ultimate).

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Thomas Dunlap
Sent: Wednesday, June 19, 2013 4:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RDz or RDzEnterprise developers

Graham,

The issue is not which version of RDz but rather which version of Windows.  
Even with RDz 7.6 the COBOL compiler would not install on Windows 7.  IBM has 
not made, plus as I understand it, a COBOL compiler which works on Windows 7.  
I am in the same position, but do have a System z to connect to as a test 
platform.

I too wish I could test locally on Windows 7.

Cheers,
Thomas Dunlap

On 6/18/2013 5:34 PM, Graham Hobbs wrote:
 Hello,

 I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and moved to a 
 new Lenovo with Windows 7. There is no need for host connection, my 
 development world is as a standalone, compile/link/run COBOL programs and 
 COBOL/CICS transaction programs on the Lenovo is the critical need.

 But I understand that Rational Developer for System z V8.5 does not 'do' 
 COBOL on Windows 7 so am thinking my new world should be Rational Developer 
 for zEnterprise V8.0.3 and would appreciate any comments/advice about that.

 Graham Hobbs

--
___
Regards,
Thomas DunlapChief Technology Officert...@themisinc.com
Themis,  Inc.http://www.themisinc.com1 (800) 756-3000

--
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: IBM commitment to academia

The classic business-school analysis of DEC's misfortunes makes them
an instance of the effects of disruptive technology: microprocessors
replacing mnicomputers.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Retrieving jobs of input queue

2013-06-19 Thread Lizette Koehler

Knowing you are using OPS/MVS would have been very helpful in providing an
answer.

I have always gone to CA OPS/MVS support for questions like this.  They have
always provided code when I needed it.

Also, try joining the OPS/MVS Newsgroup at PROTECH

ESMA Listserver automat...@listserv.protechtraining.com

Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of k Zaf
Sent: Wednesday, June 19, 2013 12:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Retrieving jobs of input queue

Hi all,

Thank you for your answers. Note that I would like to bypass in my REXX the
use of address ISFEXEC or ISFACT. This is because I am not using standard
TSO REXX but OPS/MVS REXX which is not supporting (yet) a host environment
to SDSF.


Kind regards


On 18 June 2013 23:35, Kirk Wolf k...@dovetail.com wrote:

 You can use the lsjes command:

 See: https://www.dovetail.com/docs/coz/dsp-ref_lsjes.html

 This could be called from REXX using bpxwunix() or the SH host command 
 environment.

 Also, the fromdsn command can be used to extract spool files for a job.

 Kirk Wolf
 Dovetailed Technologies
 http://dovetail.com

 PS The Co:Z Toolkit is free to download and use under our Community
 License.
 Enterprise License and Support agreements are also available:
 http://dovetail.com/support.html

 On Tue, Jun 18, 2013 at 9:17 AM, K kzafi...@gmail.com wrote:

  Hello all
 
  Could I retrieve Jobs and their jobids of JES2 input queue though 
  REXX
 but
  WITHOUT use of SDSF.
 
  Kind regards
  Kostas
 
  
  -- For IBM-MAIN subscribe / signoff / archive access instructions, 
  send email to lists...@listserv.ua.edu with the message: INFO 
  IBM-MAIN
 

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


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

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

Re: Ported Tools - Unix

In 7405709421112672.wa.paulgboulderaim@listserv.ua.edu, on
06/17/2013
   at 08:37 PM, Paul Gilmartin paulgboul...@aim.com said:

On Mon, 17 Jun 2013 20:30:19 -0400, Shmuel Metz (Seymour J.)  wrote:

Will they only offer Perl 5.8.7, or will they offer a more current
Perl?

Did Il cimento dell'EBCDIC e dell'UNICODE ever get resolved in
Perl?

There's some experimental work, but the Perldela for 5.18 warns that
they will drop the MVS support if nobody is willing to pick up the
ball. I believe that they're more concerned about test systems than
they are about developers, but that they need both.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IBM commitment to academia

2013-06-19 Thread Anne Lynn Wheeler

jwgli...@gmail.com (John Gilmore) writes:
 The classic business-school analysis of DEC's misfortunes makes them
 an instance of the effects of disruptive technology: microprocessors
 replacing mnicomputers.

re:
http://www.garlic.com/~lynn/2013h.html#76 DataPower XML Appliance and RACF
http://www.garlic.com/~lynn/2013h.html#78 IBM commitment to academia

vax sold into the same mid-range market as 4300s and except for large
corporate orders, in about the same numbers. the large corporate 4300s
orders hundred to large hundreds at a time to be placed out in
departmental areas was sort of the leading edge of the distributed
computing tsunami wave. these distributed vm/4300s inside ibm
contributed to scarcity of conference rooms inside ibm (i.e. they were
going out into departmental supply rooms and conferences rooms) and big
contributer to the internal network passing 1000 nodes in 1983 ... the
internal network was larger than the arpanet/internet from just about
the beginning until sometime late '85 or early '86 ... some past posts
http://www.garlic.com/~lynn/subnetwork.html#internalnet

it also contributed to ibm coming out with the 3375 ... emulated CKD on
FBA 3370. I had been told that even if I provided fully integrated
and tested FBA support to MVS, I still needed a $26M business case
to cover education, training, and documentation ... oh and I couldn't
use long-term life-cycle changes ... I could only use incremental
new sales ... and customers were already buying as much disk as
could be made ... so customers would just switch from same amount
of FBA as they had been buying CKD. some past posts
http://www.garlic.com/~lynn/submain.html#dasd

the issue was that 3380s were the high-end disk ... and the only disks
in the lowmid-range were FBA. MVS couldn't participant in this huge
explosion in distributed processing on 4300s ... in part because it
didn't have support for disk that was suitable in non-datacenter
environments. Disk division was forced into producing 3375 (CKD emulated
on 3370) ... however MVS support paradigm also didn't scale well to
running on hundreds of distributed systems.

old post with decade of vax sales, sliceddiced by US/non-US, year,
model
http://www.garlic.com/~lynn/2002f.html#0

clusters of 4300s also represented threat to 3033 ... they had more
aggregate processing power than 3033 and were significantly cheaper and
required significantly less floor space and environmental resources.  at
one point, POK 3033 was playing internal politics and got the allocation
of critical 4300 manufacturing component cut in half. old 4300-related
email
http://www.garlic.com/~lynn/lhwemail.html#43xx

in the decade of vax sales, towards the end, it is possible to see
workstations and large PCs moving up into the mid-range market.
something similar happened to 4300s ... the 4331/4341 followons
(4361/4381) was expecting to continued explosion in sales ... but the
mid-range market was already starting to move (4361/4381 suffering same
effects as vax).

before 4300s shipped, there were engineering 4341 models in disk
engineeringtest ... and I had better access to 4341 for doing
benchmarks than the performance group in (endicott) 4341 manufacturing.
one of the benchmarks that I ran was for LLNL ... that were looking at
buying 70 4341 for compute cluster ... if they met certain performance 
price/performance requirements. old reference
http://www.garlic.com/~lynn/2006y.html#email790220

sort of start of being involved with LLNL compute clusters ... reference
to more than decade later on cluster scaleup ... recent post with
old email
http://www.garlic.com/~lynn/2013h.html#email910808

other old email on cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

within hrs of the last email in the above, cluster scaleup was
transferred and we were told we couldn't work on anything with more than
four processors ... and within week or two, it was announced as IBM
supercomputer.

I was also working with Jim Gray on original relational/SQL
implementation ... system/r ... originally done on vm 370/145 in
bldg. 28 (san jose research). early joint study on system/r
was with bank of america. Old email from Jim about BofA
doing 60 vm/4341s and I needed to further reduce the effort
to manage large numbers of distributed machines.
http://www.garlic.com/~lynn/2006y.html#email800311b

later when Jim was leaving for Tandem ... he was palming
bunch of stuff on me (including dealing with BofA, DBMS
consulting with IMS group, etc)
http://www.garlic.com/~lynn/2007.html#email801016

system/r folklore is that mainstream corporate attention was focused on
EAGLE ... and was able to do technology transfer and get System/R out
(under the radar) through Endicott as SQL/DS.  Later when EAGLE
imploded, the System/R group was asked how fast could they do a port to
MVS ... which eventually comes out as DB2. misc. past posts
http://www.garlic.com/~lynn/submain.html#systemr

the late 80s was when senior disk engineer got a talk

Re: Auditing vendor source code

Perhaps there is a place for a trusted third party who can audit the
source and issue some sort of assurance that the vendor could then attach.
Of course, this suffers from a number of problems. Such as cost. The need
to get a new certification after every change (or perhaps level set or
release). Finding said trusted third party. Trust is difficult to come
by today. IMO, if I don't generally trust the vendor, or at least their
intentions, then I guess I shouldn't get their software (my attitude
towards MS and even Apple any more). Not that it's my call for Enterprise
Software. Here, it is more about hard money cost.

On Wed, Jun 19, 2013 at 8:08 AM, Phil Smith p...@voltage.com wrote:

 This is an interesting dilemma. FWIW, in almost 30 years as a vendor, I've
 never had anyone ask to see source code for security reasons. That doesn't
 mean it won't happen tomorrow, of course.

 I suspect that the general attitude is a synthesis of the comments here:

 -  Vendors are assumed to have competent people (yeah, yeah, let's
 not go there!)

 -  Customers don't necessarily think they would be able to grok in
 fullness and spot any weaknesses

 -  Customers are used to not seeing source code (and yes, that's a
 whole 'nother discussion)

 -  Customers auditing it could shift some of the responsibility to
 them

 Basically, while a lot of techies have probably thought of asking to do
 so, they or their management have seen it as a rat-hole down which they
 dare not go. Again, this is my guess based on *MY* experience, YMMV etc.

 ...phsiii

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




-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

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: Retrieving jobs of input queue

I am not too familiar with how to do it, but there is a way to have
CA-OPS/MVS dispatch work into a TSO server address space (ADDRESS TSO,
ADDRESS OSF, ...). I don't know exactly how those work. We have CA-OPS/MVS
and I have some knowledge of it. I may try writing a CA-OPS/MVS rule which
does includes something like:

xx=isfcalls(ON)
address isf
...

I don't know if the OP has tried this or not. Should work in a TSO server,
I would guess. Assuming SDSF is in the LINKLIST.

On Wed, Jun 19, 2013 at 8:16 AM, Lizette Koehler stars...@mindspring.comwrote:

 Knowing you are using OPS/MVS would have been very helpful in providing an
 answer.

 I have always gone to CA OPS/MVS support for questions like this.  They
 have
 always provided code when I needed it.

 Also, try joining the OPS/MVS Newsgroup at PROTECH

 ESMA Listserver automat...@listserv.protechtraining.com

 Lizette


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of k Zaf
 Sent: Wednesday, June 19, 2013 12:20 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Retrieving jobs of input queue

 Hi all,

 Thank you for your answers. Note that I would like to bypass in my REXX the
 use of address ISFEXEC or ISFACT. This is because I am not using standard
 TSO REXX but OPS/MVS REXX which is not supporting (yet) a host environment
 to SDSF.


 Kind regards


 On 18 June 2013 23:35, Kirk Wolf k...@dovetail.com wrote:

  You can use the lsjes command:
 
  See: https://www.dovetail.com/docs/coz/dsp-ref_lsjes.html
 
  This could be called from REXX using bpxwunix() or the SH host command
  environment.
 
  Also, the fromdsn command can be used to extract spool files for a job.
 
  Kirk Wolf
  Dovetailed Technologies
  http://dovetail.com
 
  PS The Co:Z Toolkit is free to download and use under our Community
  License.
  Enterprise License and Support agreements are also available:
  http://dovetail.com/support.html
 
  On Tue, Jun 18, 2013 at 9:17 AM, K kzafi...@gmail.com wrote:
 
   Hello all
  
   Could I retrieve Jobs and their jobids of JES2 input queue though
   REXX
  but
   WITHOUT use of SDSF.
  
   Kind regards
   Kostas
  
   
   -- For IBM-MAIN subscribe / signoff / archive access instructions,
   send email to lists...@listserv.ua.edu with the message: INFO
   IBM-MAIN
  
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions, send
  email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 

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

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




-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

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: Check out GE Hiring Thousands of Engineers to Build Industrial Web - Business

In b2200.2d69ddd2.3ef15...@aol.com, on 06/18/2013
   at 02:21 AM, Ed Finnell efinnel...@aol.com said:

_GE  Hiring Thousands of Engineers to Build Industrial Web -
Businessweek_ 
(http://www.businessweek.com/news/2013-06-17/ge-hiring-thousands-of-engineers
-to-build-industrial-internet)  

The Internet is not the web!

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: SMF70INT format

2013-06-19 Thread Roland Kinsman

Do you have File-AID/MVS?  It does come with a collection of SMF record layouts 
coded in PL/I.  Unfortunately, it has not been maintained for some time, but 
the layouts are still valid.  There is a separate manual for using the layouts. 
 It's called SMF Record Mapping Reference JES V4.  You can get to it on the 
support site, http://go.compuware.com 

Here's the statement from that manual regarding currency: Most SMF record 
changes for JES V4 are downward compatible to SMF records generated by earlier 
versions of JES. In some cases, new fields have been added to the end of some 
SMF records and will not be shown when mapping SMF records from earlier 
versions.

With that layout, you can do all kinds of magic with File-AID batch, probably 
including the calculations you refer to in your original message.

Hope that helps!

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

Re: Auditing vendor source code

2013-06-19 Thread Roland Kinsman

I think in terms of auditing the source code for nefarious operations, there is 
a kind of “mutual assured destruction” principle at work here.  If a vendor was 
so careless with their source code as to allow some kind of scam to be done 
with their code, the ensuing scandal would simply ruin that vendor.  In the 
interest of self-preservation no vendor would ever allow their code to be 
misused in such a way.

Interesting that this should come up at this time.  We just recently had one of 
our highest-revenue customers request a description of the function of each 
load module in our APF libraries.  We provided between 2 and 6 words per 
module, and that satisfied their auditor.  IBM publishes the same type of 
information – 
http://www-03.ibm.com/systems/z/os/zos/features/lang_environment/assist/modr9nic.html

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

Re: XCF / GRS

2013-06-19 Thread Art Gutowski

On Tue, 18 Jun 2013 12:51:14 -0400, August Carideo august.cari...@avon.com 
wrote:

Has anyone converted XCF / GRS ( CNC / CTC ) from ESCON to FICON ?
we are looking into this because EC12 has no ESCON thanks to those
Einsteins at IBM
[...]
But this question is really geared towards GRS etc. so ignore rest of my
rant

It's not that bad.  I liked not having to track CTC/CNC pairs any more.  At a 
previous shop the migration was seamless, however...

- We moved from shared ESCON channels.  From experience, dedicated ESCON (or 
3088) migration to shared FICON CTCs are more involved.  If you are on 
dedicated paths, take the time and effort to understand and implement shared 
CTCs.  I took a page from a colleagues' playbook and drew a chart for the 
migrations.  Adding in devices later was much easier with established numbering 
conventions.  Pay particular attention to CUADD on your CTC control units.

- We had FICON directors to run the FCTC channels through.  If you have more 
than one CEC, especially if you are connecting across buildings, FICON 
directors are worth consideration for redundancy and bandwidth.  While 
directors also enable you to share FCTC channels with other devices, I wouldn't 
recommend piggy-backing XCF CTCs with other devices.

- Obtain and read the FICON Planning and Implementation Guide Redbook:
http://www.redbooks.ibm.com/abstracts/sg246497.html?Open

There is a FICON CTC RedPaper, but it's over 10 years old, and hopefully 
incorporated into the Redbook.

Good luck,
Art Gutowski

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

Re: Auditing vendor source code

In my experience customers are often less concerned with looking at
source code themselves than they are with its availability after an
ISV, particularly a small one, has ceased to be.

I know of a number of arrangements in which current versions of some
product systematically replace deposited older ones under the terms of
a formal escrow agreement, from which they are releasable iff an ISV
ceases to be viable, with viability variously but not very
controversially defined.

Such schemes have the merit that they are ancient, much litigated, and
thus well understood, at least by the lawyers involved on both sides.
There are also bridges in place that make them meaningful/usable in
contexts where many other anglo-saxon legal notions are not
operational.


John Gilmore, Ashland, MA 01721 - USA

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

Re: Ported Tools - Unix

On Wed, 19 Jun 2013 09:20:37 -0400, Shmuel Metz (Seymour J.) wrote:

Did Il cimento dell'EBCDIC e dell'UNICODE ever get resolved in
Perl?

There's some experimental work, but the Perldela for 5.18 warns that
they will drop the MVS support if nobody is willing to pick up the
ball. I believe that they're more concerned about test systems than
they are about developers, but that they need both.
 
(ITYM Perldelta.  But GIYF.)  From:

http://search.cpan.org/dist/perl-5.18.0/pod/perldelta.pod

Future Deprecations ^

Platforms without support infrastructure

Both Windows CE and z/OS have been historically under-maintained, and are 
currently neither successfully building nor regularly being smoke tested. 
Efforts are underway to change this situation, but it should not be taken for 
granted that the platforms are safe and supported. If they do not become 
buildable and regularly smoked, support for them may be actively removed in 
future releases. If you have an interest in these platforms and you can lend 
your time, expertise, or hardware to help support these platforms, please let 
the perl development effort know by emailing perl5-port...@perl.org.

Alas.  If the build were easier, the testing would be trivial.

I hate EBCDIC!

-- gil

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

Re: Auditing vendor source code

2013-06-19 Thread David L. Craig

On 13Jun19:0608-0700, Phil Smith wrote:

 This is an interesting dilemma. FWIW, in almost 30
 years as a vendor, I've never had anyone ask to see
 source code for security reasons. That doesn't mean
 it won't happen tomorrow, of course.
 
 I suspect that the general attitude is a synthesis
 of the comments here:
 
 - Vendors are assumed to have competent people (yeah,
   yeah, let's not go there!)
 
 - Customers don't necessarily think they would be
   able to grok in fullness and spot any weaknesses
 
 - Customers are used to not seeing source code
   (and yes, that's a whole 'nother discussion)
 
 - Customers auditing it could shift some of the
   responsibility to them
 
 Basically, while a lot of techies have probably
 thought of asking to do so, they or their management
 have seen it as a rat-hole down which they dare not
 go. Again, this is my guess based on *MY* experience,
 YMMV etc.

You don't suppose everyone believes the NSA and CIA are
doing an excellent job of looking out for us normal
customers, especially for stuff like the HMCs and SEs?
-- 
not cent from sell
May the LORD God bless you exceedingly abundantly!

Dave_Craig__
So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
__--from_Nightfall_by_Asimov/Silverberg_

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

Re: Ported Tools - Unix

2013-06-19 Thread Anne Lynn Wheeler

paulgboul...@aim.com (Paul Gilmartin) writes:
 I hate EBCDIC!

old reference that EBCDIC was one of the biggest goofs for 360 ...  was
supposed to have been ascii ... EBCDIC and the P-Bit (The Biggest
Computer Goof Ever)
http://www.bobbemer.com/P-BIT.HTM

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

JES2/Jobtrac - Converter post error

2013-06-19 Thread baby eklavya

Hi,

We are running Z/os 1.11 in our environment and we use jobtrac for
scheduling the jobs . Some times , we get issues where the jobs fail
with instantly when jobtrac tries to submit it . When checked with CA
, they couldn't tell exactly if this is a problem with Jobtrac or JES2
.The SVC dumps didn't help much . Whenever this happens , an SVC dump
is captured for JES2 and i see the below messages in the log . Has
anyone encountered this problem before ?

*IEA794I SVC DUMP HAS CAPTURED: 628
 DUMPID=023 REQUESTED BY JOB (JES2)
 DUMP TITLE=GJTRUJV2 CONVERTER POST ERROR
 IEF196I CA-JOBTRAC - CONVERTER POST ERROR
 TRAC024C - ZAVAN2K HAS IMPROPER DEPENDENCIES, SUBMISSION DENIED.
 CA-JOBTRAC - CONVERTER POST ERROR
 IEF196I CA-JOBTRAC - CONVERTER POST ERROR
 TRAC024C - ZAVAN2K HAS IMPROPER DEPENDENCIES, SUBMISSION DENIED.


Thanks in Advance ,
baby

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

Re: JES2/Jobtrac - Converter post error

2013-06-19 Thread Lizette Koehler

I would open a case with CA JOBTRAC and send them the dump

Lizette

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of baby eklavya
Sent: Wednesday, June 19, 2013 7:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2/Jobtrac - Converter post error

Hi,

We are running Z/os 1.11 in our environment and we use jobtrac for
scheduling the jobs . Some times , we get issues where the jobs fail with
instantly when jobtrac tries to submit it . When checked with CA , they
couldn't tell exactly if this is a problem with Jobtrac or JES2 .The SVC
dumps didn't help much . Whenever this happens , an SVC dump is captured for
JES2 and i see the below messages in the log . Has anyone encountered this
problem before ?

*IEA794I SVC DUMP HAS CAPTURED: 628
 DUMPID=023 REQUESTED BY JOB (JES2)
 DUMP TITLE=GJTRUJV2 CONVERTER POST ERROR  IEF196I CA-JOBTRAC - CONVERTER
POST ERROR  TRAC024C - ZAVAN2K HAS IMPROPER DEPENDENCIES, SUBMISSION DENIED.
 CA-JOBTRAC - CONVERTER POST ERROR
 IEF196I CA-JOBTRAC - CONVERTER POST ERROR  TRAC024C - ZAVAN2K HAS IMPROPER
DEPENDENCIES, SUBMISSION DENIED.

Thanks in Advance ,
baby

--
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: IBM commitment to academia

2013-06-19 Thread Gerhard Postpischil


On 6/19/2013 7:36 AM, John Gilmore wrote:

The classic business-school analysis of DEC's misfortunes makes them
an instance of the effects of disruptive technology: microprocessors
replacing mnicomputers.


That might answer the how, but not the why. I attribute it to bad 
management that failed to innovate in a timely fashion, didn't provide 
proper technical direction (1), nor effective sales. Ultimately I blame 
Ken Olsen: There is no reason for any individual to have a computer in 
his home. (2)   As a glaring example of this. DEC marketed three 
distinct lines of PCs, all failures.


Gerhard Postpischil
Bradford, Vermont


(1) AMS acquired a DEC-System 20 in the seventies. To get acquainted 
with it, I tried a Monopoly game (about 1000 lines) written in BASIC. 
The source files were rounded up to a word boundary, padded with nulls. 
After a system update that tracked exact file length, loading an old 
file resulted in an error message for each null.


(2) In a talk given to a 1977 World Future Society meeting in Boston. 
Olsen later explained that he was referring to smart homes rather than 
personal computers. At snopes.com is an article explaining that his 
statement, in original context, was a little more plausible - he meant 
computers that controlled operation of a house, not a PC.


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

Re: JES2/Jobtrac - Converter post error

The GJTRUJV2 in the dump title gives the impression that this is the IEFUJV
exit for CA-Jobtrac. They need to debug it. If this is like other CA
products, you first need to use AMATERSE to create an FB compressed version
of the SYSDUMP data set (SYS1.DUMPnn or dynamically allocated dump dataset,
whichever you use at your shop). Then open a support issue with CA and
attach the aforementioned AMATERSE output to the request.

On Wed, Jun 19, 2013 at 9:33 AM, Lizette Koehler stars...@mindspring.comwrote:

 I would open a case with CA JOBTRAC and send them the dump

 Lizette


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of baby eklavya
 Sent: Wednesday, June 19, 2013 7:31 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: JES2/Jobtrac - Converter post error

 Hi,

 We are running Z/os 1.11 in our environment and we use jobtrac for
 scheduling the jobs . Some times , we get issues where the jobs fail with
 instantly when jobtrac tries to submit it . When checked with CA , they
 couldn't tell exactly if this is a problem with Jobtrac or JES2 .The SVC
 dumps didn't help much . Whenever this happens , an SVC dump is captured
 for
 JES2 and i see the below messages in the log . Has anyone encountered this
 problem before ?

 *IEA794I SVC DUMP HAS CAPTURED: 628
  DUMPID=023 REQUESTED BY JOB (JES2)
  DUMP TITLE=GJTRUJV2 CONVERTER POST ERROR  IEF196I CA-JOBTRAC - CONVERTER
 POST ERROR  TRAC024C - ZAVAN2K HAS IMPROPER DEPENDENCIES, SUBMISSION
 DENIED.
  CA-JOBTRAC - CONVERTER POST ERROR
  IEF196I CA-JOBTRAC - CONVERTER POST ERROR  TRAC024C - ZAVAN2K HAS IMPROPER
 DEPENDENCIES, SUBMISSION DENIED.


 Thanks in Advance ,
 baby

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




-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

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: Ported Tools - Unix

Without, of course, agreeing with them, I am, again of course,
familiar with Paul Gilmartin's 'I hate EBCDIC' refrain.  More
interesting in the question: Do he and that ilk despise UNICODE in
equal measure?

He quotes Shmuel's question

| Did Il cimento dell'EBCDIC e dell'UNICODE ever get
| resolved in Perl?

which, even as an Italian speaker, I find mystifying.  Shmuel may well
be alluding to something specific that I wot not of, but the Italian
verb 'cimentare' means 'to put to the test',  'il cimento' means 'the
test' or 'the trial'; and all of this is gloriously inspecific.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Ported Tools - Unix

Why would anybody who likes ASCII despise UNICODE? I could easily be
confused, but US-ASCII is a proper subset of UNICODE. In particular, of
UTF-8. Unless I have misunderstood everything I've ever read about Unicode.
And both are close, but not identical(?), to ISO8859-1. I normally tag
z/OS UNIX files which are ascii as ISO8859-1.

On Wed, Jun 19, 2013 at 9:49 AM, John Gilmore jwgli...@gmail.com wrote:

 Without, of course, agreeing with them, I am, again of course,
 familiar with Paul Gilmartin's 'I hate EBCDIC' refrain.  More
 interesting in the question: Do he and that ilk despise UNICODE in
 equal measure?

 He quotes Shmuel's question

 | Did Il cimento dell'EBCDIC e dell'UNICODE ever get
 | resolved in Perl?

 which, even as an Italian speaker, I find mystifying.  Shmuel may well
 be alluding to something specific that I wot not of, but the Italian
 verb 'cimentare' means 'to put to the test',  'il cimento' means 'the
 test' or 'the trial'; and all of this is gloriously inspecific.

 John Gilmore, Ashland, MA 01721 - USA

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




-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

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: Retrieving jobs of input queue

On Wed, 19 Jun 2013 08:26:39 -0500, John McKown wrote:

I am not too familiar with how to do it, but there is a way to have
CA-OPS/MVS dispatch work into a TSO server address space (ADDRESS TSO,
ADDRESS OSF, ...). I don't know exactly how those work. We have CA-OPS/MVS
and I have some knowledge of it. I may try writing a CA-OPS/MVS rule which
does includes something like:

xx=isfcalls(ON)
address isf
...

I don't know if the OP has tried this or not. Should work in a TSO server,
I would guess. Assuming SDSF is in the LINKLIST.

What need for TSO?  address SDSF works fine for me in a non-TSO
address space.  (Is there an address ISF?)

If the OPS/MVS environment lacks the SDSF command processor, it
might be either an integrity requirement, or just plain oversight, kinda
like the SH command processor's being unavailable in some address
spaces.

-- gil

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

Re: JES2/Jobtrac - Converter post error

2013-06-19 Thread baby eklavya

Thanks Lizette and John for the response .

Actually , i had already sent the dumps to CA but they couldn't figure
out the exact reason . But they suspect that Jobtrac post converter
error message is caused as when  many jobs  are submitted at the same
time, then it can happen that message TRAC024C - 'job has improper
dependencies, submission denied' is issued for those jobs and an svc
dump with dump title - GJTRUJV2 - converter post error is issued. CA
suggested a PTF to be installed which might help capture more
diagnostic data next time if it occurs .

John ,

GJTRUJV2 is the IEFUJV exit for CA Jobtrac . But , i was wondering how
a product specific exit like GJTRUJV2 gets the control when there is
already IEFUJV (default JES2 validation exit) enabled on the system .
Could you throw some light on how these kind of external exits work ?

Regards,
Baby



On 6/19/13, John McKown john.archie.mck...@gmail.com wrote:
 The GJTRUJV2 in the dump title gives the impression that this is the IEFUJV
 exit for CA-Jobtrac. They need to debug it. If this is like other CA
 products, you first need to use AMATERSE to create an FB compressed version
 of the SYSDUMP data set (SYS1.DUMPnn or dynamically allocated dump dataset,
 whichever you use at your shop). Then open a support issue with CA and
 attach the aforementioned AMATERSE output to the request.

 On Wed, Jun 19, 2013 at 9:33 AM, Lizette Koehler
 stars...@mindspring.comwrote:

 I would open a case with CA JOBTRAC and send them the dump

 Lizette


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of baby eklavya
 Sent: Wednesday, June 19, 2013 7:31 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: JES2/Jobtrac - Converter post error

 Hi,

 We are running Z/os 1.11 in our environment and we use jobtrac for
 scheduling the jobs . Some times , we get issues where the jobs fail with
 instantly when jobtrac tries to submit it . When checked with CA , they
 couldn't tell exactly if this is a problem with Jobtrac or JES2 .The SVC
 dumps didn't help much . Whenever this happens , an SVC dump is captured
 for
 JES2 and i see the below messages in the log . Has anyone encountered
 this
 problem before ?

 *IEA794I SVC DUMP HAS CAPTURED: 628
  DUMPID=023 REQUESTED BY JOB (JES2)
  DUMP TITLE=GJTRUJV2 CONVERTER POST ERROR  IEF196I CA-JOBTRAC - CONVERTER
 POST ERROR  TRAC024C - ZAVAN2K HAS IMPROPER DEPENDENCIES, SUBMISSION
 DENIED.
  CA-JOBTRAC - CONVERTER POST ERROR
  IEF196I CA-JOBTRAC - CONVERTER POST ERROR  TRAC024C - ZAVAN2K HAS
 IMPROPER
 DEPENDENCIES, SUBMISSION DENIED.


 Thanks in Advance ,
 baby

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




 --
 This is a test of the Emergency Broadcast System. If this had been an
 actual emergency, do you really think we'd stick around to tell you?

 Maranatha! 
 John McKown

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


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

Test, please ignore

I don't get my own postings. I see other people's postings, I see their
answers to my postings, so my postings do reach the listserv, and are
not rejected. My mailserver look not guilty as well, because I see
other postings.

Now I changed one setting: from NOACK REPRO to ACK NOREPRO.

--
Radoslaw Skorupka
Lodz, Poland

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

Other hardware discontinued. (was 2084-D48?)

2013-06-19 Thread Dana Mitchell

In that same announcement,  IBM also announced discontinuance of maintenance 
for 

9032 003
9032 005
9037 002

Good thing we are considering starting a migration to CECs that support STP!

Dana

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

Re: Auditing vendor source code

Right, but a very different issue.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Wednesday, June 19, 2013 6:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Auditing vendor source code

In my experience customers are often less concerned with looking at source
code themselves than they are with its availability after an ISV,
particularly a small one, has ceased to be.

I know of a number of arrangements in which current versions of some product
systematically replace deposited older ones under the terms of a formal
escrow agreement, from which they are releasable iff an ISV ceases to be
viable, with viability variously but not very controversially defined.

Such schemes have the merit that they are ancient, much litigated, and thus
well understood, at least by the lawyers involved on both sides.
There are also bridges in place that make them meaningful/usable in contexts
where many other anglo-saxon legal notions are not operational.

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

Re: RDz or RDzEnterprise developers

2013-06-19 Thread Graham Hobbs


Thomas, Barry,
Sorry to bother you again. Any chance you think/know that RDz 7.6 would run 
under XP virtual machine? If I downloaded/installed 7.6 (from SAC) do you 
think IBM may have removed the COBOL compiler?

Cheers,
Graham

- Original Message - 
From: Thomas Dunlap thomas.dun...@att.net

Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 19, 2013 5:06 AM
Subject: Re: RDz or RDzEnterprise developers



Graham,

The issue is not which version of RDz but rather which version of Windows. 
Even with RDz 7.6 the COBOL compiler would not install on Windows 7.  IBM 
has not made, plus as I understand it, a COBOL compiler which works on 
Windows 7.  I am in the same position, but do have a System z to connect 
to as a test platform.


I too wish I could test locally on Windows 7.

Cheers,
Thomas Dunlap



On 6/18/2013 5:34 PM, Graham Hobbs wrote:

Hello,

I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and moved 
to a new Lenovo with Windows 7. There is no need for host connection, my 
development world is as a standalone, compile/link/run COBOL programs and 
COBOL/CICS transaction programs on the Lenovo is the critical need.


But I understand that Rational Developer for System z V8.5 does not 'do' 
COBOL on Windows 7 so am thinking my new world should be Rational 
Developer for zEnterprise V8.0.3 and would appreciate any comments/advice 
about that.

  Graham Hobbs


--
___
Regards,
Thomas DunlapChief Technology Officert...@themisinc.com
Themis,  Inc.http://www.themisinc.com1 (800) 756-3000

--
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: IBM commitment to academia

On Wed, 19 Jun 2013 10:36:59 -0400, Gerhard Postpischil wrote:

... Ultimately I blame
Ken Olsen: There is no reason for any individual to have a computer in
his home. (2)   As a glaring example of this. DEC marketed three
distinct lines of PCs, all failures.

He was only trying to prove his point.

-- gil

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

Re: Auditing vendor source code

You are correct.

There is security by obscurity at work here, no question:

- If a rogue employee had our listings and link maps he might well be able to 
patch our code to not do its job in certain circumstances, thereby creating a 
security exposure (assuming he had write access to the load library, or to 
protected memory).

- Our key (licensing, whatever you want to call it) is definitely protection 
by obscurity. If you knew exactly how it worked, you could defeat it, and run 
our product forever on every mainframe in the world.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, June 18, 2013 11:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Auditing vendor source code

On Tue, 18 Jun 2013 16:45:09 -0700, Charles Mills wrote:

... So it would not necessarily be in great a position to steal 
customer data itself, but if we were malicious, and conspired with a 
rogue employee, we could perhaps jointly steal valuable data.

..., nor how to defeat our keys. ...
 
'keys' sounds a lot like backdoor or 'magic' SVC.  I.e.
anything which if a customer's rogue employee knew it could be used to 
compromise system security.

Imagine, very hypothetically, that you had no concerns for your IP.  Then not 
letting the entire world see all your source code would amount to security by 
obscurity.

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

Re: Other hardware discontinued. (was 2084-D48?)

W dniu 2013-06-19 17:r37, Dana Mitchell pisze:

In that same announcement, IBM also announced discontinuance of maintenance for

9032 003
9032 005
9037 002

Good thing we are considering starting a migration to CECs that support STP!

Well, that would mean you are using pre-z/990 machines, are you?

Note that using (pre)-historical machine models is neither illegal nor
impossible and the announcement will not change to much except you
cannot have any support *from IBM*. You can still use the machine, still
fix it or replace it it it broken.

BTW: I have three 9032-002's, none of them was under service ever.
Purchased in 2000 from a broker, 2 boxes were in production, third was
for hot spare. During the years we repaired one of the boxes - failed
power supply was replaced (the box have redundant supplies).

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Other hardware discontinued. (was 2084-D48?)

2013-06-19 Thread Ken Porowski

Did anyone notice that z890's (2086) were left out of the list?



CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 
740 5459 (tel) | ken.porow...@cit.com



This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.



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

Re: Auditing vendor source code

On Wed, 19 Jun 2013 08:42:10 -0700, Charles Mills wrote:

- ... (assuming he had write access to the load library, or to protected 
memory).
 
Il va sans dire.

- Our key (licensing, whatever you want to call it) is definitely 
protection by obscurity. If you knew exactly how it worked, you could defeat 
it, and run our product forever on every mainframe in the world.
 
Is there any licensing scheme for which that is not true?
It can be as simple as zapping a mask in a branch taken
when validation fails.

I imagine encrypting the executable code, and letting the preamble
call home to get the current day's decryption key.  But I still see
holes.

STRAWMANOr run the entire application in the cloud, where the
vendor could retain control./STRAWMAN

-- gil

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

Re: Auditing vendor source code

Charles Mills wrote:
Our key (licensing, whatever you want to call it) is definitely protection 
by obscurity. If you knew exactly how it worked, you could defeat it, and run 
our product forever on every mainframe in the world.

So this is a slightly different topic, but it's been my experience that CPUIDs 
(keys, whatever you want to call 'em) are more trouble than they're worth. 
Any sysprog worth his salary can break them in minutes if desired; the hassles 
at the vendor end of getting 3AM calls due to expiration, etc. make 'em not 
worth the trouble. I've seen exactly ONE case where we found someone running an 
unlicensed copy; that was a mistake, and was a full-price bluebird, so we 
didn't mind at all. Contracts control licenses, not code.

My $0.02.

...phsiii

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

Re: Auditing vendor source code

Perhaps the simplest way would be to somehow have an entire subroutine
encrypted. The subroutine would be self relocating in order to avoid
address constants. The encryption key would be somehow tied to the CPUID
and the date. When you get a new key, you also get a new encrypted
subroutine. The main code does a STORAGE OBTAIN to get storage, reads and
decrypts the subroutine into to. Then addresses the subroutine via a
special call macro which gets the address via a name/token pair.

Personally, I would likely do what I've seen a book publisher do. Each book
is subtly different in inconsequential ways. But he can do a SHA-1 on the
book, compare against his database, and find the purchaser. Although,
IANAL, this would most likely hold up in court. Maybe not for a single
second user. But for 10s or 100s? Sure. IBM, or other vendors, could do the
same. Generate a passcode of some sort. This passcode would influence the
resultant object module in ways which do not affect its results. Keep a
SHA-1 of the program objects. At execution, check the SHA-1 in various
places along with the passcode. If something doesn't match, give some
spurious error message which is documented like: Serious internal error
detected. Contact support. Code=... Let them report themselves.

On Wed, Jun 19, 2013 at 11:03 AM, Paul Gilmartin paulgboul...@aim.comwrote:

 On Wed, 19 Jun 2013 08:42:10 -0700, Charles Mills wrote:
 
 - ... (assuming he had write access to the load library, or to
 protected memory).
 
 Il va sans dire.

 - Our key (licensing, whatever you want to call it) is definitely
 protection by obscurity. If you knew exactly how it worked, you could
 defeat it, and run our product forever on every mainframe in the world.
 
 Is there any licensing scheme for which that is not true?
 It can be as simple as zapping a mask in a branch taken
 when validation fails.

 I imagine encrypting the executable code, and letting the preamble
 call home to get the current day's decryption key.  But I still see
 holes.

 STRAWMANOr run the entire application in the cloud, where the
 vendor could retain control./STRAWMAN

 -- gil

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




-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

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: Retrieving jobs of input queue

In 5068302466122345.wa.kzafiropgmail@listserv.ua.edu, on
06/18/2013
   at 09:17 AM, K kzafi...@gmail.com said:

Could I retrieve Jobs and their jobids of JES2 input queue though
REXX but WITHOUT use of SDSF. 

In theory, yes, but you'd have to use job names of userid plus one
character, which makes it impractical.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Auditing vendor source code

In 099ee5bc-1948-4595-96ce-5115309e9...@yahoo.com, on 06/18/2013
   at 08:30 PM, Scott Ford scott_j_f...@yahoo.com said:

We don't worry about we have customers who sign NDAs ...but I am old
school I resist providing source code,

That's not old school; old school is we don't provide object code -
you compile.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Auditing vendor source code

In 51c127d4.6020...@blackhillsoftware.com, on 06/19/2013
   at 01:39 PM, Andrew Rowley and...@blackhillsoftware.com said:

How many vendors do allow you to audit their authorized code? I know
IBM is very reluctant to divulge any information that might allow
you to exploit a vulnerability.

Until OCO IBM provided customers with full access to the source code.
What they controlled was the details of security APAR's. I would not
expect any responsible vendor to publish a list of known security
exploits, just the fixes.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Auditing vendor source code

In
b870629719727b4ba82a6c06a31c291239e0e0c...@hqmailsvr01.voltage.com,
on 06/19/2013
   at 06:08 AM, Phil Smith p...@voltage.com said:

I suspect that the general attitude is a synthesis of the comments
here:

A few more possibilities:

-  Customers may lack the resources to audit every thing
that they would like to.

-  Customers auditing the source code are under an NDA or
otherwise not allowed to mention it here.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IBM commitment to academia

In
985915eee6984740ae93f8495c624c6c231975f...@jscpcwexmaa1.bsg.ad.adp.com,
on 06/18/2013
   at 10:24 AM, Farley, Peter x23353 peter.far...@broadridge.com
said:

It is my faded-memory impression that it was, as Timothy pointed out,
DEC's aggressive push of very low-cost and free stuff into
universities that both permitted and accelerated the rise of *ix and
also contributed to the decline of IBM mainframes on campus (though
that was not the only reason). 

It didn't help that the MVS address space was painfully small compared
to the VAX. It wasn't until MVS/ESA that IBM caught up.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Retrieving jobs of input queue

2013-06-19 Thread Ed Jaffe


On 6/19/2013 7:53 AM, Shmuel Metz (Seymour J.) wrote:

In 5068302466122345.wa.kzafiropgmail@listserv.ua.edu, on
06/18/2013
at 09:17 AM, K kzafi...@gmail.com said:


Could I retrieve Jobs and their jobids of JES2 input queue though
REXX but WITHOUT use of SDSF.

In theory, yes, but you'd have to use job names of userid plus one
character, which makes it impractical.


JES3 customers have long used the following:

++SRCUPD(IATUX30) .
./ CHANGE NAME=IATUX30
UX30SETB  1

to replace IKJEFF53 with IATUX30 for FIB security processing. JES2 has 
no similar modification?


These days I see a lot of FTP used for product-neutral JES access 
scripting. JESINTERFACELEVEL=2 is recommended.


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

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

Re: Retrieving jobs of input queue

2013-06-19 Thread Itschak Mugzach

Ed,
this is what i suggested - using ftp. The only problem is that if you use
ISFPARMS for securing jes resources, you are in trouble. RACF must be in
place for FTP (or any other non SDSF interface.

ITschak


On Wed, Jun 19, 2013 at 7:49 PM, Ed Jaffe edja...@phoenixsoftware.comwrote:

 On 6/19/2013 7:53 AM, Shmuel Metz (Seymour J.) wrote:

 In 
 5068302466122345.WA.**kzafiropgmail@listserv.ua.**edu5068302466122345.wa.kzafiropgmail@listserv.ua.edu,
 on
 06/18/2013
 at 09:17 AM, K kzafi...@gmail.com said:

  Could I retrieve Jobs and their jobids of JES2 input queue though
 REXX but WITHOUT use of SDSF.

 In theory, yes, but you'd have to use job names of userid plus one
 character, which makes it impractical.


 JES3 customers have long used the following:

 ++SRCUPD(IATUX30) .
 ./ CHANGE NAME=IATUX30
 UX30SETB  1

 to replace IKJEFF53 with IATUX30 for FIB security processing. JES2 has no
 similar modification?

 These days I see a lot of FTP used for product-neutral JES access
 scripting. JESINTERFACELEVEL=2 is recommended.

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


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


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

Re: RDz or RDzEnterprise developers

2013-06-19 Thread Thomas Dunlap


Graham,

I believe RDz 7.6 does include the COBOL compiler, even 8.0 does. You 
just have to install and run on XP Pro.  I have not tried what Barry 
mentions, running XP compatible virtual process under Windows 7.  I have 
a co-worker that used it for awhile with mixed results, some things 
worked and some did not.


How about a laptop with dual boot, both XP Pro and Windows 7.

Cheers,
Thomas Dunlap


On 6/19/2013 11:39 AM, Graham Hobbs wrote:

Thomas, Barry,
Sorry to bother you again. Any chance you think/know that RDz 7.6 
would run under XP virtual machine? If I downloaded/installed 7.6 
(from SAC) do you think IBM may have removed the COBOL compiler?

Cheers,
Graham

- Original Message - From: Thomas Dunlap 
thomas.dun...@att.net

Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 19, 2013 5:06 AM
Subject: Re: RDz or RDzEnterprise developers



Graham,

The issue is not which version of RDz but rather which version of 
Windows. Even with RDz 7.6 the COBOL compiler would not install on 
Windows 7.  IBM has not made, plus as I understand it, a COBOL 
compiler which works on Windows 7.  I am in the same position, but do 
have a System z to connect to as a test platform.


I too wish I could test locally on Windows 7.

Cheers,
Thomas Dunlap



On 6/18/2013 5:34 PM, Graham Hobbs wrote:

Hello,

I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and 
moved to a new Lenovo with Windows 7. There is no need for host 
connection, my development world is as a standalone, 
compile/link/run COBOL programs and COBOL/CICS transaction programs 
on the Lenovo is the critical need.


But I understand that Rational Developer for System z V8.5 does not 
'do' COBOL on Windows 7 so am thinking my new world should be 
Rational Developer for zEnterprise V8.0.3 and would appreciate any 
comments/advice about that.

  Graham Hobbs


--
___
Regards,
Thomas DunlapChief Technology Officert...@themisinc.com
Themis,  Inc.http://www.themisinc.com1 (800) 756-3000

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




--
___
Regards,
Thomas DunlapChief Technology Officert...@themisinc.com
Themis,  Inc.http://www.themisinc.com1 (800) 756-3000

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

Re: Auditing vendor source code

On Wed, 19 Jun 2013 09:17:09 -0700, Phil Smith wrote:

So this is a slightly different topic, but it's been my experience that CPUIDs 
(keys, whatever you want to call 'em) are more trouble than they're worth. 
Any sysprog worth his salary can break them in minutes if desired; the hassles 
at the vendor end of getting 3AM calls due to expiration, etc. make 'em not 
worth the trouble. I've seen exactly ONE case where we found someone running 
an unlicensed copy; that was a mistake, and was a full-price bluebird, so we 
didn't mind at all. Contracts control licenses, not code.
 
Apparently.  I've held the same job for three different employers
through corporate acquisitions.  The latest one required that we
scrub all our keys, forthwith,

-- gil

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

Re: Auditing vendor source code

Paul Gilmartin wrote:
Apparently.  I've held the same job for three different employers
through corporate acquisitions.  The latest one required that we
scrub all our keys, forthwith,

I'm sorry, I must be dense-I don't understand what this means. The keys were 
dirty? :) Seriously, what did they have you do with them?

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

Re: Auditing vendor source code

2013-06-19 Thread Ed Jaffe


On 6/19/2013 9:17 AM, Phil Smith wrote:
So this is a slightly different topic, but it's been my experience 
that CPUIDs (keys, whatever you want to call 'em) are more trouble 
than they're worth.


We once had a situation in which a foreign distributor had numerous 
off-book customers using our software illegally. It's not clear 
whether the customers actually realized they were pirating the software. 
In any case, the implementation of so-called keys put a stop to all 
subsequent attempts at deliberate or accidental misuse (as far as we 
know, of course)...


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

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

Re: Other hardware discontinued. (was 2084-D48?)

2013-06-19 Thread Dana Mitchell

On Wed, 19 Jun 2013 17:49:36 +0200, R.S. r.skoru...@bremultibank.com.pl wrote:

 Good thing we are considering starting a migration to CECs that support STP!

Well, that would mean you are using pre-z/990 machines, are you?

Currently on z9's without STP installed.

Dana

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

Re: IBM commitment to academia

2013-06-19 Thread Anne Lynn Wheeler

shmuel+...@patriot.net (Shmuel Metz  , Seymour J.) writes:
 It didn't help that the MVS address space was painfully small compared
 to the VAX. It wasn't until MVS/ESA that IBM caught up.

re:
http://www.garlic.com/~lynn/2013h.html#76 DataPower XML Appliance and RACF
http://www.garlic.com/~lynn/2013h.html#78 IBM commitment to academia
http://www.garlic.com/~lynn/2013i.html#2 IBM commitment to academia
http://www.garlic.com/~lynn/2013i.html#4 IBM commitment to academia

during the Future System period ... 370 (hardware  software)
development was being killed off (and lack of new products
is credited with giving clone processors market foothold).
with death of FS ... there was mad rush to get products
back into the 370 pipeline ... misc. past posts
http://www.garlic.com/~lynn/submain.html#futuresys

part of that was 303x in parallel with 3081  370/xa. The head of POK
also managed to convince corporate to kill off the vm370 product,
shutdown the burlington mall development group and move all the people
to POK ... or otherwise he wouldn't be able to meet the mvs/xa ship
schedule.

the burlington mall group wasn't going to be told until the very last
moment in order to minimize people being able to escape ...  however it
leaked a few months early ... and quite a few people were able to escape
the move to POK ... quite a few going to DEC to work on vax/vms (this
was in the very early days of starting vax/vms development)
... resulting in the head of POK being considered one of the biggest
contributors to vax/vms.

endicott eventually managed to save the vm370 product mission ... but
had to reconsitute a development group from scratch ... the resulting
learning curve resulted in quite a few comments on VMSHARE during the
period.
http://vm.mairist.edu/~vmshare/

there was also quite a bit of enhancements to vm370 lost in the
burlington mall shutdown ... including a major expansion of MVS
emulation in cms.

-- 
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: Auditing vendor source code

2013-06-19 Thread Mike Schwab

On Wed, Jun 19, 2013 at 8:22 AM, John McKown
john.archie.mck...@gmail.com wrote:
 Perhaps there is a place for a trusted third party who can audit the
 source and issue some sort of assurance that the vendor could then attach.
 Of course, this suffers from a number of problems. Such as cost. The need
 to get a new certification after every change (or perhaps level set or
 release). Finding said trusted third party. Trust is difficult to come
 by today. IMO, if I don't generally trust the vendor, or at least their
 intentions, then I guess I shouldn't get their software (my attitude
 towards MS and even Apple any more). Not that it's my call for Enterprise
 Software. Here, it is more about hard money cost.

Marketing your product through IBM Partner World is essential a seal
of approval from IBM.
They have at least tested it and should be able to find any problems
with the product that a customer reports.

Is there any product tracking statistics that compare pre-
Partnerworld and Post Partnerworld sales levels?
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Auditing vendor source code

Ed Jaffe wrote:
We once had a situation in which a foreign distributor had numerous off-book 
customers using our software illegally. It's not clear whether the customers 
actually realized they were pirating the software. In any case, the 
implementation of so-called keys put a stop to all subsequent attempts at 
deliberate or accidental misuse (as far as we know, of course)...

As you note, as far as we know. If the distributor was that dishonest, I 
assume this meant that the US folks had to handle all keys? I bet that was 
fun...lots of off-hours calls!

Yeah, the only argument I've ever heard that had any teeth was related to them 
untrustworthy furriners. Though I suspect it's less that foreign companies are 
less trustworthy than that American companies are more afraid of litigation...

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

Re: Auditing vendor source code

2013-06-19 Thread Mike Schwab

This was true in DOS 6.X.  The object modules would be loaded into
memory, and the first thing the program would do was decompress the
rest of the module into another memory area and run from there.  This
was when software to compress DOS disks was becoming popular.  But it
would run on any PC.

On Wed, Jun 19, 2013 at 11:17 AM, John McKown
john.archie.mck...@gmail.com wrote:
 Perhaps the simplest way would be to somehow have an entire subroutine
 encrypted. The subroutine would be self relocating in order to avoid
 address constants. The encryption key would be somehow tied to the CPUID
 and the date. When you get a new key, you also get a new encrypted
 subroutine. The main code does a STORAGE OBTAIN to get storage, reads and
 decrypts the subroutine into to. Then addresses the subroutine via a
 special call macro which gets the address via a name/token pair.

This was true in DOS 6.X.  The object modules would be loaded into
memory, and the first thing the program would do was decompress the
rest of the module into another memory area and run from there.  This
was when software to compress DOS disks was becoming popular.  But it
would run on any PC.

 Personally, I would likely do what I've seen a book publisher do. Each book
 is subtly different in inconsequential ways. But he can do a SHA-1 on the
 book, compare against his database, and find the purchaser. Although,
 IANAL, this would most likely hold up in court. Maybe not for a single
 second user. But for 10s or 100s? Sure. IBM, or other vendors, could do the
 same. Generate a passcode of some sort. This passcode would influence the
 resultant object module in ways which do not affect its results. Keep a
 SHA-1 of the program objects. At execution, check the SHA-1 in various
 places along with the passcode. If something doesn't match, give some
 spurious error message which is documented like: Serious internal error
 detected. Contact support. Code=... Let them report themselves.

What some people do to pass a secret message.  They choose a high
resolution BMP photo file, set the low order bits to contain their
message (a photo viewer would only show slightly changed colors) then
send the changed file, and the intended recipient would reverse the
encoding to view the message.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Auditing vendor source code

On Wed, 19 Jun 2013 11:01:20 -0700, Phil Smith wrote:

I'm sorry, I must be dense-I don't understand what this means. The keys were 
dirty? :) Seriously, what did they have you do with them?
 
I took a verbal shortcut.  I should have said we had to scrub all our
software to cleanse away the filthy keys.  I suspect we put them in
a key safe in case a future corporate acquisition re-re-verses the
policy.

On Wed, 19 Jun 2013 13:10:14 -0700, Phil Smith wrote:

As you note, as far as we know. If the distributor was that dishonest, I 
assume this meant that the US folks had to handle all keys? I bet that was 
fun...lots of off-hours calls!
 
In part.  If the keys are CPU-specific and only the vendor, not the
distributor, knows the incantation for generating keys, the opportunity
for distributor dishonesty is curtailed.  But the vendor still needs to
be the locksmith for lost key incidents.

-- gil

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

Re: Auditing vendor source code

Exactly. We had one of those at my last company. Distributor stole *a
little* from us by selling off-book features that were not key controlled.
Same distributor stole over $1MM from a small software company where that
might have been a 20-30% increase in their sales. He was able to do it
because they gave him the key generator. Story would have been no different
if the software had had no keys.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Ed Jaffe
Sent: Wednesday, June 19, 2013 11:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Auditing vendor source code

On 6/19/2013 9:17 AM, Phil Smith wrote:
 So this is a slightly different topic, but it's been my experience 
 that CPUIDs (keys, whatever you want to call 'em) are more trouble 
 than they're worth.

We once had a situation in which a foreign distributor had numerous
off-book customers using our software illegally. It's not clear whether
the customers actually realized they were pirating the software. 
In any case, the implementation of so-called keys put a stop to all
subsequent attempts at deliberate or accidental misuse (as far as we know,
of course)...

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

Re: Auditing vendor source code

2013-06-19 Thread Tom Marchant

On Wed, 19 Jun 2013 15:00:00 -0500, Mike Schwab wrote:

Marketing your product through IBM Partner World is essential a seal
of approval from IBM.

Is it really?

They have at least tested it and should be able to find any problems
with the product that a customer reports.

Who has?  IBM?

-- 
Tom Marchant

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

Re: Auditing vendor source code

I wondered about those assertions ...

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, June 19, 2013 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Auditing vendor source code

On Wed, 19 Jun 2013 15:00:00 -0500, Mike Schwab wrote:

Marketing your product through IBM Partner World is essential a seal of 
approval from IBM.

Is it really?

They have at least tested it and should be able to find any problems 
with the product that a customer reports.

Who has?  IBM?

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

Re: Auditing vendor source code

Tom Marchant wrote:
Marketing your product through IBM Partner World is essential a seal
of approval from IBM.

Is it really?

Um, no. Well...maybe some customers see it as such, but they should know better.

They have at least tested it and should be able to find any problems
with the product that a customer reports.

Who has?  IBM?

Again, no. IBM doesn't test products before letting vendors list them on PWD!

...phsiii

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

Re: Run TSO batch as different user?

2013-06-19 Thread Gord Tomlin


...which will of course lead to controversy! ;)


--

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

On 2013-06-19 17:34, Gord Tomlin wrote:

Did you try adding the userid and password to the job card?

--

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

On 2013-06-19 17:21, Charles Mills wrote:

Here's an easier and less controversial question. I have used IKJEFT01
lots
of times in batch jobs to run TSO commands. IKJEFT01 always runs as my
userid, the userid under which I submit the batch job.

Can I get IKJEFT01 to run under a different userid, a userid for which I
have the password? How?

I tried adding

LOGON otherid/password

and several variations thereof as the first line of SYSTSIN but my
SYSTSPRT
ends after the LOGON statement with no diagnostics anywhere that I can
find.

I tried RTFM but don't see anything. Not saying it's not there, saying I
didn't find it.

Thanks!

Charles

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




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




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

Re: Auditing vendor source code

On Wed, 19 Jun 2013 14:34:25 -0700, Phil Smith wrote:

They have at least tested it and should be able to find any problems
with the product that a customer reports.

Who has?  IBM?

Again, no. IBM doesn't test products before letting vendors list them on PWD!
 
Even the App Store claims to do that.  But they may mostly filter for
dirty pictures, which need to be scrubbed.

-- gil

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

Re: Run TSO batch as different user?

On Wed, 19 Jun 2013 17:34:17 -0400, Gord Tomlin wrote:

Did you try adding the userid and password to the job card?
 
It might be that the OP's desire is that the TMP run under a user ID
different from the parent job's, not that the parent job be constrained
to run under the user ID intended for the TMP.


On 2013-06-19 17:21, Charles Mills wrote:
 Here's an easier and less controversial question. I have used IKJEFT01 lots
 of times in batch jobs to run TSO commands. IKJEFT01 always runs as my
 userid, the userid under which I submit the batch job.

 Can I get IKJEFT01 to run under a different userid, a userid for which I
 have the password? How?

Ummm...  Run a UNIX Rexx program that does a setuid, validating credentials
as necessary, then issues the newfangled address TSO?  WAG.  Untested.

Might this use SSL credentials?

-- gil

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

Re: Run TSO batch as different user?

Thanks. Solved the problem. I'm good.

Believe it or not I've never in 44 years of MVS used JOB USER= before that I
recall. 

Addressing various issues:

- Mmm, yes, I can see why coding the password on the JOB card could be
controversial. :-(
- True, this is an answer to a different question but no, I don't care if
the job runs under the other userid also.

Seems odd to me that the facility I actually asked about does not exist.
Seems like a very reasonable sort of thing (neglecting the password issue).

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gord Tomlin
Sent: Wednesday, June 19, 2013 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Run TSO batch as different user?

Did you try adding the userid and password to the job card?

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

Re: Run TSO batch as different user?

2013-06-19 Thread Ed Jaffe


On 6/19/2013 2:34 PM, Gord Tomlin wrote:

Did you try adding the userid and password to the job card?


Best to add USER= only and use SURROGAT authority (RACF term, substitute 
appropriate OEM security product term as needed) rather than specifying 
a password in the clear.


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

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

Re: Run TSO batch as different user?

2013-06-19 Thread Gibney, Dave

You don't need to put the password on the job card if you have SURROGAT access 
to the required userid.

Darn, I see Ed beat me to this. :)

Dave Gibney
Information Technology Services
Washington State University


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Charles Mills
 Sent: Wednesday, June 19, 2013 3:09 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Run TSO batch as different user?
 
 Thanks. Solved the problem. I'm good.
 
 Believe it or not I've never in 44 years of MVS used JOB USER= before that I
 recall.
 
 Addressing various issues:
 
 - Mmm, yes, I can see why coding the password on the JOB card could be
 controversial. :-(
 - True, this is an answer to a different question but no, I don't care if
 the job runs under the other userid also.
 
 Seems odd to me that the facility I actually asked about does not exist.
 Seems like a very reasonable sort of thing (neglecting the password issue).
 
 Charles
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 Behalf Of Gord Tomlin
 Sent: Wednesday, June 19, 2013 2:34 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Run TSO batch as different user?
 
 Did you try adding the userid and password to the job card?
 
 --
 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: IBM commitment to academia

2013-06-19 Thread Gerhard Postpischil


On 6/19/2013 11:14 AM, John Gilmore wrote:

Retreat from the unfamiliar, back into the familiar, is common.  I
suspect that we are all guilty of it from time to time; and terms like
'good management' and 'bad management' describe outcomes without being
diagnostic.


Unless one is in the possession of detailed data, unlikely to become 
public, it is difficult to judge why a company makes decisions. It is 
doubtful that clinical kainophobia is pertinent; more likely factors are 
cash flow, risk aversion, sales projections, and other non-technical 
issues. For a successful company like DEC, technical aspects were the 
least of their problems, as they had exemplary staff, including some 
ex-IBMers. This is why I conclude that their collapse and sale was due 
to poor management, even if that doesn't provide any specifics.



Olsen was a remarkable man; and in DEC he created a remarkable if not
a long-lived organization.


I see an analogue with physicists, who are reputed to make all great 
discoveries when young, and very little thereafter. Once you have the 
second largest computer company, what incentive is there to gamble it 
away, rather than progress incrementally?


Gerhard Postpischil
Bradford, Vermont

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

Re: Run TSO batch as different user?

Thanks. Will look into that.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gibney, Dave
Sent: Wednesday, June 19, 2013 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Run TSO batch as different user?

You don't need to put the password on the job card if you have SURROGAT
access to the required userid.

Darn, I see Ed beat me to this. :)

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

Re: Run TSO batch as different user?

2013-06-19 Thread Mike Schwab

Most job scheduler programs can assign other user IDs and authenticate them.

On Wed, Jun 19, 2013 at 5:08 PM, Charles Mills charl...@mcn.org wrote:
 Thanks. Solved the problem. I'm good.

 Believe it or not I've never in 44 years of MVS used JOB USER= before that I
 recall.

deleted
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of Gord Tomlin
 Sent: Wednesday, June 19, 2013 2:34 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Run TSO batch as different user?

 Did you try adding the userid and password to the job card?

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Other hardware discontinued. (was 2084-D48?)

W dniu 2013-06-19 20:23, Dana Mitchell pisze:

On Wed, 19 Jun 2013 17:49:36 +0200, R.S. r.skoru...@bremultibank.com.pl wrote:

Good thing we are considering starting a migration to CECs that support STP!

Well, that would mean you are using pre-z/990 machines, are you?

Currently on z9's without STP installed.

Well, STP is matter of microcode upgrade. It is possible anytime unless
IBM is reluctant to do it. I'm not sure about z9, but it can be
expensive, because of IBM policy.
BTW: AFAIK, In order to have z9 in sysplex timer network it was
necessary to order some features (timer card) to z9.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Other hardware discontinued. (was 2084-D48?)

2013-06-19 Thread Skip Robinson

The opportunity to do any upgrade whatever on z9 or even z10 has long 
expired. If you could afford to buy your way out of this problem, you 
could afford fresh iron. ;-)

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   R.S. r.skoru...@bremultibank.com.pl
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   06/19/2013 04:00 PM
Subject:Re: Other hardware discontinued. (was 2084-D48?)
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



W dniu 2013-06-19 20:23, Dana Mitchell pisze:
 On Wed, 19 Jun 2013 17:49:36 +0200, R.S. 
r.skoru...@bremultibank.com.pl wrote:
 Good thing we are considering starting a migration to CECs that 
support STP!

 Well, that would mean you are using pre-z/990 machines, are you?
 Currently on z9's without STP installed.

Well, STP is matter of microcode upgrade. It is possible anytime unless 
IBM is reluctant to do it. I'm not sure about z9, but it can be 
expensive, because of IBM policy.
BTW: AFAIK, In order to have z9 in sysplex timer network it was 
necessary to order some features (timer card) to z9.

-- 
Radoslaw Skorupka
Lodz, Poland


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

Re: JES2/Jobtrac - Converter post error

2013-06-19 Thread baby eklavya

I am trying to understand if it is possible to have 2 different UJV exits
active at the same time , one for Jobtrac scheduled jobs and the other one
for all other jobs submitted to JES2 . If that's the case , then Jobtrac
should be probably passing/setting a flag to use GJTRUJV2 before the job is
submitted to JES2





On Wed, Jun 19, 2013 at 8:54 PM, baby eklavya baby.ekla...@gmail.comwrote:

 Thanks Lizette and John for the response .

 Actually , i had already sent the dumps to CA but they couldn't figure
 out the exact reason . But they suspect that Jobtrac post converter
 error message is caused as when  many jobs  are submitted at the same
 time, then it can happen that message TRAC024C - 'job has improper
 dependencies, submission denied' is issued for those jobs and an svc
 dump with dump title - GJTRUJV2 - converter post error is issued. CA
 suggested a PTF to be installed which might help capture more
 diagnostic data next time if it occurs .

 John ,

 GJTRUJV2 is the IEFUJV exit for CA Jobtrac . But , i was wondering how
 a product specific exit like GJTRUJV2 gets the control when there is
 already IEFUJV (default JES2 validation exit) enabled on the system .
 Could you throw some light on how these kind of external exits work ?

 Regards,
 Baby



 On 6/19/13, John McKown john.archie.mck...@gmail.com wrote:
  The GJTRUJV2 in the dump title gives the impression that this is the
 IEFUJV
  exit for CA-Jobtrac. They need to debug it. If this is like other CA
  products, you first need to use AMATERSE to create an FB compressed
 version
  of the SYSDUMP data set (SYS1.DUMPnn or dynamically allocated dump
 dataset,
  whichever you use at your shop). Then open a support issue with CA and
  attach the aforementioned AMATERSE output to the request.
 
  On Wed, Jun 19, 2013 at 9:33 AM, Lizette Koehler
  stars...@mindspring.comwrote:
 
  I would open a case with CA JOBTRAC and send them the dump
 
  Lizette
 
 
  -Original Message-
  From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
  Behalf Of baby eklavya
  Sent: Wednesday, June 19, 2013 7:31 AM
  To: IBM-MAIN@LISTSERV.UA.EDU
  Subject: JES2/Jobtrac - Converter post error
 
  Hi,
 
  We are running Z/os 1.11 in our environment and we use jobtrac for
  scheduling the jobs . Some times , we get issues where the jobs fail
 with
  instantly when jobtrac tries to submit it . When checked with CA , they
  couldn't tell exactly if this is a problem with Jobtrac or JES2 .The SVC
  dumps didn't help much . Whenever this happens , an SVC dump is captured
  for
  JES2 and i see the below messages in the log . Has anyone encountered
  this
  problem before ?
 
  *IEA794I SVC DUMP HAS CAPTURED: 628
   DUMPID=023 REQUESTED BY JOB (JES2)
   DUMP TITLE=GJTRUJV2 CONVERTER POST ERROR  IEF196I CA-JOBTRAC -
 CONVERTER
  POST ERROR  TRAC024C - ZAVAN2K HAS IMPROPER DEPENDENCIES, SUBMISSION
  DENIED.
   CA-JOBTRAC - CONVERTER POST ERROR
   IEF196I CA-JOBTRAC - CONVERTER POST ERROR  TRAC024C - ZAVAN2K HAS
  IMPROPER
  DEPENDENCIES, SUBMISSION DENIED.
 
 
  Thanks in Advance ,
  baby
 
  --
  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
 
 
 
 
  --
  This is a test of the Emergency Broadcast System. If this had been an
  actual emergency, do you really think we'd stick around to tell you?
 
  Maranatha! 
  John McKown
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions,
  send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 


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

Re: RDz or RDzEnterprise developers

2013-06-19 Thread Graham Hobbs

Another good suggestion. Will do some investigating, so thanks Thomas 
and Barry.

Graham

Ruminating only: being smallfry, what use then is RDz/TXSeries if a 
mainframe is a must.


On 19/06/2013 1:26 PM, Thomas Dunlap wrote:

Graham,

I believe RDz 7.6 does include the COBOL compiler, even 8.0 does. You 
just have to install and run on XP Pro.  I have not tried what Barry 
mentions, running XP compatible virtual process under Windows 7.  I 
have a co-worker that used it for awhile with mixed results, some 
things worked and some did not.


How about a laptop with dual boot, both XP Pro and Windows 7.

Cheers,
Thomas Dunlap


On 6/19/2013 11:39 AM, Graham Hobbs wrote:

Thomas, Barry,
Sorry to bother you again. Any chance you think/know that RDz 7.6 
would run under XP virtual machine? If I downloaded/installed 7.6 
(from SAC) do you think IBM may have removed the COBOL compiler?

Cheers,
Graham

- Original Message - From: Thomas Dunlap 
thomas.dun...@att.net

Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 19, 2013 5:06 AM
Subject: Re: RDz or RDzEnterprise developers



Graham,

The issue is not which version of RDz but rather which version of 
Windows. Even with RDz 7.6 the COBOL compiler would not install on 
Windows 7.  IBM has not made, plus as I understand it, a COBOL 
compiler which works on Windows 7.  I am in the same position, but 
do have a System z to connect to as a test platform.


I too wish I could test locally on Windows 7.

Cheers,
Thomas Dunlap



On 6/18/2013 5:34 PM, Graham Hobbs wrote:

Hello,

I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and 
moved to a new Lenovo with Windows 7. There is no need for host 
connection, my development world is as a standalone, 
compile/link/run COBOL programs and COBOL/CICS transaction programs 
on the Lenovo is the critical need.


But I understand that Rational Developer for System z V8.5 does not 
'do' COBOL on Windows 7 so am thinking my new world should be 
Rational Developer for zEnterprise V8.0.3 and would appreciate any 
comments/advice about that.

  Graham Hobbs


--
___
Regards,
Thomas DunlapChief Technology Officer t...@themisinc.com
Themis,  Inc.http://www.themisinc.com1 (800) 756-3000

--
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: Auditing vendor source code

2013-06-19 Thread Ed Gould


John:

I would be extremely reluctant to buy any such product.
In one place I worked the serial numbers changed continuously  
(monthly) and we had one or two vendors that stuck it to us because  
of a bad key they sent and we literally had to back out of CPU  
upgrades because they didn't have 24/7 support.


Ed

On Jun 19, 2013, at 11:17 AM, John McKown wrote:

Perhaps the simplest way would be to somehow have an entire  
subroutine

encrypted. The subroutine would be self relocating in order to avoid
address constants. The encryption key would be somehow tied to the  
CPUID

and the date. When you get a new key, you also get a new encrypted
subroutine. The main code does a STORAGE OBTAIN to get storage,  
reads and

decrypts the subroutine into to. Then addresses the subroutine via a
special call macro which gets the address via a name/token pair.

Personally, I would likely do what I've seen a book publisher do.  
Each book
is subtly different in inconsequential ways. But he can do a SHA-1  
on the

book, compare against his database, and find the purchaser. Although,
IANAL, this would most likely hold up in court. Maybe not for a single
second user. But for 10s or 100s? Sure. IBM, or other vendors,  
could do the
same. Generate a passcode of some sort. This passcode would  
influence the
resultant object module in ways which do not affect its results.  
Keep a

SHA-1 of the program objects. At execution, check the SHA-1 in various
places along with the passcode. If something doesn't match, give some
spurious error message which is documented like: Serious internal  
error

detected. Contact support. Code=... Let them report themselves.

On Wed, Jun 19, 2013 at 11:03 AM, Paul Gilmartin  
paulgboul...@aim.comwrote:



On Wed, 19 Jun 2013 08:42:10 -0700, Charles Mills wrote:


- ... (assuming he had write access to the load library, or to

protected memory).



Il va sans dire.


- Our key (licensing, whatever you want to call it) is definitely
protection by obscurity. If you knew exactly how it worked, you  
could
defeat it, and run our product forever on every mainframe in the  
world.



Is there any licensing scheme for which that is not true?
It can be as simple as zapping a mask in a branch taken
when validation fails.

I imagine encrypting the executable code, and letting the preamble
call home to get the current day's decryption key.  But I still see
holes.

STRAWMANOr run the entire application in the cloud, where the
vendor could retain control./STRAWMAN

-- gil

- 
-

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






--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! 
John McKown

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


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

Re: JES2/Jobtrac - Converter post error

2013-06-19 Thread Thomas Conley


On 6/19/2013 10:31 AM, baby eklavya wrote:

Hi,

We are running Z/os 1.11 in our environment and we use jobtrac for
scheduling the jobs . Some times , we get issues where the jobs fail
with instantly when jobtrac tries to submit it . When checked with CA
, they couldn't tell exactly if this is a problem with Jobtrac or JES2
.The SVC dumps didn't help much . Whenever this happens , an SVC dump
is captured for JES2 and i see the below messages in the log . Has
anyone encountered this problem before ?

*IEA794I SVC DUMP HAS CAPTURED: 628
  DUMPID=023 REQUESTED BY JOB (JES2)
  DUMP TITLE=GJTRUJV2 CONVERTER POST ERROR
  IEF196I CA-JOBTRAC - CONVERTER POST ERROR
  TRAC024C - ZAVAN2K HAS IMPROPER DEPENDENCIES, SUBMISSION DENIED.
  CA-JOBTRAC - CONVERTER POST ERROR
  IEF196I CA-JOBTRAC - CONVERTER POST ERROR
  TRAC024C - ZAVAN2K HAS IMPROPER DEPENDENCIES, SUBMISSION DENIED.


Thanks in Advance ,
baby



I was at a site ages ago when JOBTRAC first came out.  TRAC024C's grew 
on trees back then.  We kept getting them with Q-autoscheds when the 
switch would bombard the mainframe with a few dozen jobs of 
long-distance tolls to rate.  They blamed it on the checkpoint.  CA 
promised that checkpoint issues would be gone with Datacom.  Sure.


This is definitely a bug in GJTRUJV2.  You shouldn't need a PTF, CA 
should be able to give you a GTF trace I would think.  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: Retrieving jobs of input queue

In 51c1e12f.7000...@phoenixsoftware.com, on 06/19/2013
   at 09:49 AM, Ed Jaffe edja...@phoenixsoftware.com said:

JES3 customers have long used the following:

++SRCUPD(IATUX30) .
./ CHANGE NAME=IATUX30
UX30SETB  1

to replace IKJEFF53 with IATUX30 for FIB security processing. JES2
has no similar modification?

I haven't seen anything that will cause TSO STATUS to return all jobs
with your userid.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Auditing vendor source code

In
b870629719727b4ba82a6c06a31c291239e0e0c...@hqmailsvr01.voltage.com,
on 06/19/2013
   at 09:17 AM, Phil Smith p...@voltage.com said:

So this is a slightly different topic, but it's been my experience
that CPUIDs (keys, whatever you want to call 'em) are more trouble
than they're worth.

Especially when the vendor fails to provide corrected/updated keys
within the contracted period.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

IBM commitment to academia|academe

καινός means 'new'; and kaino[lo]phobia, fear of the new, probably
figures in most such problems; but attachment to the successful old is
usually more important; and this attachment is often crucial when the
successful old was in its time innovative.

DEC technology, once itself disruptive, confronted another disruptive
technology in turn; and DEC's management responded dismissively and in
the event inadequately, fatally so.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Run TSO batch as different user?