Re: COND= running a step that it should not. WHY? BFOM! Options

2007-08-07 Thread Jeffrey D. Smith
Actually, any RC=9 will skip the step. I always have to rethink the
COND= to mean SKIP=. That is, if the condition holds true, then SKIP
the step. My brain implicitly tries to think the opposite, that the
step should execute only if the condition is true. It's really a
conditional SKIP expression. Weird.

/J

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of J R
 Sent: Tuesday, August 07, 2007 1:23 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: COND= running a step that it should not. WHY? BFOM! Options
 
 The step should be executed unless any prior step has RC9.
 
 
 Neal Eckhardt said:
 OK, I'm usually pretty good at spotting these things, but this one has me
 baffled.
 
 z/OS 1.4 system and here is the JCL setup
 
 
 Job card with COND=(9,LT).
 
 
 An IF/THEN/ELSE/ENDIF construct with another IF/THEN/ELSE/ENDIF imbeded
 in
 the first one.
 
 
 A PROC that has an override COND.STEPX=(4,LT,SORT0035) for a step within
 the PROC, and the above mentioned IF/THEN/ELSE/ENDIF is also contained
 within the PROC.
 
 
 Following the outer IF/ENDIF construct, outside of the PROC is a step
 with
 COND=(9,LT). This step is executing. Looking at all of the Return Codes
 for
 this execution, all steps finished with a RC=0 except for one step that
 ended with a RC=4. Several steps were FLUSHED due to the IF/ENDIF
 testing.
 
 
 For the life of me, I cannot see why this step is running.
 
 
 Can anybody throw ANY ideas my way to explain this?
 
 
 Thanks, Neal

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Theft of spindles was Re: PCI Compliance - Encryption of all non-console administrative access.

2007-08-06 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Thomas Kern
 Sent: Monday, August 06, 2007 10:12 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Theft of spindles was Re: PCI Compliance - Encryption of all
 non-console administrative access.
 
 While the corporate/government espionage agent may not be as technically
 savy as the local sysprog or CE, when they get the stolen media back to
 their headquarters, it would get turned over to real experts. Just because
 the incidents to-date have been fairly benign, doesn't mean that
 professional thieves have not stolen data, they just haven't been
 discovered
 yet. That is the sign of a good thief, that you haven't noticed the theft
 yet.
 
 /Tom Kern

Reminds me of the famous quote from a CEO of a large corporation,
We have never had an undetected security breach.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: KEY8 CSA: Pro/JCL and Info/XE

2007-07-29 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Craddock, Chris
 Sent: Sunday, July 29, 2007 8:17 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: KEY8 CSA: Pro/JCL and Info/XE
 
/snip/
 It may be the case that I'm just having a senior moment, but I would
 also -swear- I used to see lots of X'0080' PKMs in SVC dumps. A PKM with
 both key 8 and 9 would have shown up as X'00C0'.
 
 Color me astonished.
 
 CC

Just write a simple batch job-step program. The first thing it does is
BAKR to save current status. Then use ESTA to extract the PKM.
The print it or use it as a R15 return code. If you step it
with a debugger, you (i.e., the debugger) may change the
environment. So, try to run it straight thru without any peeking/poking
around.

Let us know what you find.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: z/OS job market (I could just scream!)

2007-07-27 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Richards.Bob
 Sent: Friday, July 27, 2007 7:26 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: z/OS job market (I could just scream!)
 
 Can I buy a few vowels? :-)
 
 Bob Richards
 
 
 For the beginning say Szczebrzeszyn, Szczecin or Pszczyna (city names).
 
 --
 Radoslaw Skorupka
/snip/

Reminds me of that little road off the I-15 interstate between
California and Nevada, named Zzxyzz Road.

/Jeffrey D Smith

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Pause elements used across multiple address spaces

2007-07-27 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Mike Kerford-Byrnes
 Sent: Friday, July 27, 2007 3:32 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Pause elements used across multiple address spaces
 
 I am in the throes of designing an application that communicates between a
 long running (IPL to Z EOD) server Address Space and multiple user Address
 Spaces.  Given the requirements, the exploitation of PAUSE/RELEASE seems,
 as
 per the documentation, to be highly suitable.  The server Address Space is
 likely to deploy an array of Pause Elements from which the most suitable
 will be selected upon each user request (of which there may be a LOT).  So
 a
 given PE may be used VERY frequently by any and/or many User Address
 Spaces.
 There is a paragraph in the Auth Assembler Guide which gives me a slight
 concern. It states:
 
 When a PE is allocated with auth_level=IEA_AUTHORIZED, the PE can be used
 to pause and release any task or SRB in the system. The same PE can be
 used,
 for example, to pause a task in address space 10. After being released,
 the
 same PE can be used to pause an SRB in, say, address space 23. ++There
 is,
 however, a small performance penalty imposed when a PE is used to pause a
 task or SRB in one space and then reused to pause a task or SRB in another
 space++.  This cost is accrued upon each space transition.
 
 I have a number of questions relating to this.   Does the accrual happen
 on
 each AS transition? For instance, if the usage happened to alternate
 between
 just two address spaces (say 10  23) would there be an accrual for EACH
 Transition, or just one per Address Space?

From my interpretation of the same documentation that you quoted, the
accrual happens each time the PE is reused to point to a different
address space.

 Secondly, given the accrual rate, however derived, is there a predictable
 point where the performance overhead could become a liability - and how
 can
 I determine it?
 
 Finally (at least for now), if the overhead has the potential of becoming
 a
 problem, would it be a wise move to maintain a usage count of each PE and
 to
 delete and reacquire once a particular limit has been reached - and if so,
 any suggestions as to the values that may be suitable?
 
 Mike Kerford-Byrnes

I would suggest not using Pause/Resume, because I don't like the
way its interface was implemented. IMHO, I think it was silly to use an
SVC routine and to require the client to decide whether to use the
authorized or unauthorized interface. A simple stacking PC routine would
have been a clean interface for both task and SRB, and it is faster than
the SVC FLIH  SLIH processing.

I would suggest using GRS latch manager, which has the same interface
for TCB or SRB mode, and works in cross memory. You can allocate a latch
set in your server space. Use space-switch PC routines to jump into the
server space and enqueue on a selected latch. The GRS latch manager
can be used quite effectively in a WAIT/POST-like scenario that works
in cross memory mode and SRB mode. You'll need an FRR EUT=YES,MODE=FULLXM
to handle clean-up when either the home space or the server space goes
away unexpectedly.

Seems a bit easier than writing code to manage a set of Pause elements
with usage counts.

2 cents worth. your mileage may vary.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: KEY8 CSA: Pro/JCL and Info/XE

2007-07-26 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Binyamin Dissen
 Sent: Thursday, July 26, 2007 1:34 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: KEY8 CSA: Pro/JCL and Info/XE
 
 On Thu, 26 Jul 2007 01:31:10 -0400 Craddock, Chris
 [EMAIL PROTECTED]
 wrote:
 
 :Ed Jaffe asks...
 : Out of curiosity, which software products allocate CSA in keys A-
 : F?
 
 :I know of one major vendor's storage management product that right up
 :until the last time I looked (more than a year ago) ran in key 10
 :(X'A0') and used a bunch of CSA in key 10. The developers thought it was
 :clever. I didn't.
 
 While I don't condone it, I don't see the exposure (unless the standard
 zOS
 problem state key mask includes key 10).
 
 --
 Binyamin Dissen [EMAIL PROTECTED]
/snip/

The standard z/OS PSW key mask (PKM) is for keys 8,9 (X'00C0' numbered
0 thru 15 left to right).

That's why I never use MODESET MODE=PROB, because the stupid SVC clobbers
the PKM to show only the current key (Broke As Designed B.A.D.).


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


z/OS job market (I could just scream!)

2007-07-26 Thread Jeffrey D. Smith
 -Original Message-
/snip/
 If you are interested please contact me at any time, this is a contract
 position with **. We can submit your resume for review and the manager
 can then decide to set up an interview with you. Please contact me at any
 time and we can discuss this further, or discuss what it is you are really
 looking for and I can keep you in mind and contact you on future
 opportunities we are notified about to see if you are interested.
 
 Thank you very much for your time and I look forward to hearing from you.
 
 Help Desk (Daily) 1-3 Yrs
 
 ID: 9935
 
 Duration:  Temp to perm opportunity with initial contract at 2-3 months.
 
 Location: Broomfield, CO.
 
 Rate: $10 to $15 an hour
 
 This position will provide * support and require at least
 3 years experience on a technical help desk. Must be proficient in MVS
 (mainframe) OS system/platform/ applications. Knowledge of Unix and NT a
 plus. Ability to analyze problems from a systems perspective, isolate to
 hardware or software to bring problem to a resolution.
 
 Thank you,
/snip/

After 30 years of developing commercial grade software, this is the kind
of opportunities that are coming my way. Has anyone else been degraded like
this? That's not a typo, it is $15 an hour for proficiency in MVS. The job
is in Broomfield Colorado, not (expletive deleted) New Delhi! 

btw: I removed identifying references to protect the guilty.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: DSPSERV

2007-07-25 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Paul D'Angelo
 Sent: Wednesday, July 25, 2007 7:15 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: DSPSERV
 
 Gabor
 
 Wouldnt  this design be much cleaner  by starting  a second address space
 whose
 sole purpose is to own the dataspace ?
 Basically it would contain all the Data Space Code to initialize/create
 and destroy the dataspace and a Console Routine to stop this Address
 space.
 
 Granted not as elagant as an SRB scheduled to run in the MASTER Address
 Space but alot cleaner.
 
 Paul D'Angelo

I agree that it may be cleaner to use an anchor space for the CADS.
However, adding a CADS to the PASN-AL will add the same ALET to all
active address spaces. There may be race conditions when the owning
space terminates and another space adds its own unrelated CADS to
the PASN-AL. The ALET may be reused. Also, the CADS should be
allocated in a system key to prevent unauthorized programs from
mucking with it.

It may be cleaner to use an ordinary SCOPE=PRIVATE data space that
is anchored only to the single PASN-AL of the owning address space
and use space-switch PC routines to access the private data space.
This will ensure that the only access to the data space is through
trusted PC routines. It also ensures that when the owning address
space terminates, any client code running will immediately lose
their bind to the owning address space (probably a S0D5 or S0D6
abend upon redispatch).

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Mainframe shops held hostage, Itanium alliance says

2007-07-25 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of McKown, John
 Sent: Wednesday, July 25, 2007 3:00 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Mainframe shops held hostage, Itanium alliance says
 
  -Original Message-
  From: IBM Mainframe Discussion List
  [mailto:[EMAIL PROTECTED] On Behalf Of Howard Brazee
  Sent: Wednesday, July 25, 2007 3:55 PM
  To: IBM-MAIN@BAMA.UA.EDU
  Subject: Re: Mainframe shops held hostage, Itanium alliance says
 
 
  On 25 Jul 2007 13:27:47 -0700, [EMAIL PROTECTED] (McKown, John)
  wrote:
 
While I appreciate everyone's appreciation, I like John's
analogy best.  :)
  
   Yeah  I'd like to see a step van carrying an Abrams tank.
  
  
  It is simple. Disassemble it at the source, ship it quickly and
  efficiently via step van, reassemble at the destination. If
  this is not
  possible, it is a fault of the design of the tank, not the
  step van or
  the process of transportation via the step van.
 
  And make sure you ship it from California to Hawaii.
 
 
 Ah, yes. But you can drive the step van onto a large power boat.
 
 --
 John McKown

Well, he did say ship it to Hawaii... doesn't that mean
putting it on a boat or vessel anymore? eek!


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is a page protected?--how to determine

2007-07-24 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Paul Schuster
 Sent: Tuesday, July 24, 2007 12:33 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Is a page protected?--how to determine
 
 Hello: I have a need to determine if an address in storage is page
 protected
 in order to determine if a PGSER UNPROTECT needs to be done.
 
 The best I have tried and seen in earlier posts is to look for a CC=1 on a
 TPROT backed up with an ESTAE.
 
 Are there any other methods to do this?
 
 Thank you.
 
 Paul Schuster

Use a loop with IVSK and TPROT for key 0. Something like this:

   L   R2,page_address
LOOP   BR  0 purge cache
   IVSK  R0,R2   page-in
   TPROT 0(R2),0 test for key zero storability
   BO  LOOP  oops, paged-out. try again
   BNZ PROT  page protected, LAP, read-only data space
   BZ  NO_PROT   not protected

Testing for key zero storability will catch page protection, or
low address protection, or read-only data space. You may want
to provide special filtering for those weird cases.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is a page protected?--how to determine

2007-07-24 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of (IBM Mainframe Discussion List)
 Sent: Tuesday, July 24, 2007 8:07 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is a page protected?--how to determine
 
 In a message dated 7/24/2007 1:33:11 A.M. Central Daylight Time,
 [EMAIL PROTECTED] writes:
 I have a need to determine if an address in storage is page  protected
 in order to determine if a PGSER UNPROTECT needs to be  done.
 
 One way, not necessarily the most elegant, is to establish an ESTAE or
 FRR,
 put your program into key 0, and do an OI into any byte in the page with
 an
 operand of X'00'.  This instruction will not change the byte being
 accessed,
 but if the page is page protected your OI will produce a S0C4 which  you
 trap
 and from which you recover in your recovery routine.  If the page  is not
 page
 protected, the next instruction after the OI will execute.
 
 Bill  Fairchild

very bad idea in general. if the page is not protected, then you
don't know what other processes are updating that page nor how
they serialize their updates. the OI is not an interlocked update
and may cause corruption when another CPU is concurrently modifying
that byte.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is a page protected?--how to determine

2007-07-24 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Paul Schuster
 Sent: Tuesday, July 24, 2007 12:33 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Is a page protected?--how to determine
 
 Hello: I have a need to determine if an address in storage is page
 protected
 in order to determine if a PGSER UNPROTECT needs to be done.
 
 The best I have tried and seen in earlier posts is to look for a CC=1 on a
 TPROT backed up with an ESTAE.
 
 Are there any other methods to do this?
 
 Thank you.
 
 Paul Schuster

In addition to what else has been posted, be very careful about
unprotecting a page that your application did not explicitly protect.

An application that uses IARVSERV to share pages with COPY_ON_WRITE
will implicitly page-protect the shared pages. When a unit of work
attempts to store into the protected page, the system catches the
PIC 0004 and copies the contents to another real frame. Then the
page table entry is modified to point to the new real frame and
the unit of work is redispatched to try the update again; this
time succeeding. The unit of work never sees the PIC 0004.

If you explicitly unprotect such a shared page, then you will
screw up shared pages scheme.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is a page protected?--how to determine

2007-07-24 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of (IBM Mainframe Discussion List)
 Sent: Tuesday, July 24, 2007 10:05 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is a page protected?--how to determine
 
 In a message dated 7/24/2007 10:56:09 A.M. Central Daylight Time,
 [EMAIL PROTECTED] writes:
 very bad idea in general. if the page is not protected, then you
 don't  know what other processes are updating that page nor how
 they serialize their  updates. the OI is not an interlocked update
 and may cause corruption when  another CPU is concurrently modifying
 that byte.
 
 OK.  Find some other instruction that will not corrupt storage by
 serializing properly on the storage and which instruction will NOT really
 change
 anything in the storage. My main idea was to execute an instruction that
 does  not
 really change anything but yet the instruction processing microcode tests
 the
 byte to be accessed for write capability in that page.
 
 I do not understand how my instruction that does not change any of the 8
 bits in a byte can possibly corrupt any bytes anywhere near that one byte
 regardless of what other CPUs or I/O operations are doing concurrently.

Because the fetch and the store are separated in time. Another CPU or an
I/O operation can store into the byte *after* your CPU fetches the byte
but *before* your CPU stores the byte. The other CPU update will be wiped
out by your CPU subsequent store into the byte.

If the application does not know how the page owner is serializing
access to the page, there is no way to attempt a safe store into
the page to detect protection.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: JAVA SAX XML parser - GOTCHA!

2007-07-20 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of McKown, John
 Sent: Friday, July 20, 2007 11:44 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: JAVA SAX XML parser - GOTCHA!
 
 This may well be documented somewhere, but I haven't has yet seen it. I
 just downloaded JBOSS 4.2.1 and am looking at it. Well, it's cheaper
 than WAS! It keeps its configuration files in XML format. Now, usually
 XML is plain text as opposed to binary. So when I created the z/OS
 JBOSS, I translated the *.xml files to EBCDIC. Bad move! I tried to
 start JBOSS and got a bunch of errors from the SAX parser that didn't
 make sense. I finally noticed on the Dovetailed Technologies web site
 for TOMCAT that they said to keep the *.xml files in ASCII. So I
 restored the ASCII version of the XML files and JBOSS came up (not that
 I know what to do with it now - still reading!). From this, it appears
 that the XML parser that comes with IBM's JDK 1.5_64 (what I am running)
 can only read ASCII encoded xml files. Isn't that a trip? Or am I doing
 something else wrong?
 
 --
 John McKown

XML files start with a header entry in UTF-8 that describes the text
format (usually the remainder of the file is also in UTF-8). Supported
text formats are from the UNICODE set. I don't know whether XML parsers
are supposed to support EBCDIC, nor how to specify EBCDIC in the XML
header entry. Even if you found a way to specify EBCDIC text format,
you must still use UTF-8 for the XML header entry. Seems simpler to
just leave the entire file in UTF-8 format.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Finally get to go from os390 2.10 to zOS 1.8

2007-06-27 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Timothy Sipples
 Sent: Wednesday, June 27, 2007 10:28 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Finally get to go from os390 2.10 to zOS 1.8
 
 Tom Kelman asks:
 Boy, those going from OS/390 V2R10 to z/OS V1R8 are making a pretty big
 leap.  We went from z/OS 1.4 to 1.7 and we're told we couldn't go
 directly to 1.8.  How are you able to skip so many releases?
 
 A pattern that's very common in Japan, for example, is a new footprint
 build.  That is, some shops will buy a new mainframe, load it up with
 current OS and software, copy the applications over and create test data,
 test thoroughly (and test again), then cutover when ready, sometimes in
 stages (if they have application silos that are separable).  It's not my
 favorite way to get the job done, and many organizations are discovering
 that rolling online upgrades really do offer numerous benefits, notably
 continuous business service delivery, but the classic method still works.
 
 Also, I don't think I'm revealing any secrets in saying that it's not just
 third parties that'll assist with giant OS version leaps.  There's an IBM
 service offering in Japan (for a fee) to leap from OS/390 V2R10 straight
 to
 z/OS 1.6 in one shot.  There are some odd government rules that pretty
 much
 force banks to do this sort of thing.
 
 All that said, it's way easier to migrate from OS/390 V2R10 to z/OS 1.8
 than it is to migrate to another operating system.  Way, way, way easier.
 And, once you do get current, please don't let this happen again.  Stick
 to
 the N-minus migration steps.  You'll be way, way, way happier.  So will
 your wallet.
 
 - - - - -
 Timothy Sipples

Wow, that is WAY WAY WAY WAY good to know!

/J

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: SVC vs APF and other 'privileged' code

2007-06-21 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Arthur T.
 Sent: Thursday, June 21, 2007 3:17 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: SVC vs APF and other 'privileged' code
 
 On 21 Jun 2007 14:03:20 -0700, in bit.listserv.ibm-main
 (Message-ID:[EMAIL PROTECTED])
 [EMAIL PROTECTED] (R.S.) wrote:
 
  From time to time I read on the list about companies
  which demand ISVs to provide source code for SVC routines
  to analyze it from security point of view.
 While I don't know to much about z/OS 'guts', I'm
 wondering what is the reason for that? Or rather, why the
 SVC code is so important, while APF-authorized libraries
 are not subject to analyze. The same apply to propgrams in
 SCHEDxx members.
 AFAIK (I could be wrong) APF-authorized program can bypass
 security rules, so it can be dangeours. Is SVC more
 dangerous ?
 
   What follows is a mixture of facts, opinion, and
 experience.  I am not pointing a finger at any particular
 companies or software packages.
 
/snip/
 
   Many companies, and some software packages, even have
 get yourself authorized SVCs.  If you know the secret
 software handshake, you can make your non-authorized
 program authorized.  Some of these SVCs do better jobs than
 others of assuring that they came from programs which are
 to be trusted.  Regardless, they're frowned on by auditors.

Every instance of the ISV get yourself authorized SVC that
I have seen is horribly broken. The only such SVC that actually
works correctly is the IBM MODESET SVC, which requires the
caller to be APF authorized (or already running in system state).

The general rule is that a program that needs to do something
authorized should put that logic on the other side of the
SVC/PC fence and do it in a controlled environment. I have not
yet seen an ISV get yourself authorized SVC that couldn't
be replaced with a correct authorized service that does it
the right way. Just sloppy or incompetent developers IMHO.
(Yes, I've been bitchslapped for complaining about bad SVC;
enuf said...)


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Read JCL Symbols from a program?

2007-06-19 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Shmuel Metz (Seymour J.)
 Sent: Tuesday, June 19, 2007 7:46 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Read JCL Symbols from a program?
 
 In [EMAIL PROTECTED], on 06/14/2007
at 06:42 AM, Ed Gould [EMAIL PROTECTED] said:
 
 IIRCC they did offer up a way to shorten the verbs  so that the 100
  character limitation was semi mute.
 
 ITYM moot, and even with abbreviations I ran into the 100 character
 limit setting up procs for IBM compilers.
 
 --
  Shmuel (Seymour J.) Metz, SysProg and JOAT

The compilers at http://www.dignus.com/ allow indirection for options.
Just specify a file name (DD name or data set name) in the PARM=
string. The compiler reads the file to get the options. Indirection
completely relieves the 100-byte limitation issue.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Read JCL Symbols from a program?

2007-06-19 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Binyamin Dissen
 Sent: Tuesday, June 19, 2007 9:30 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Read JCL Symbols from a program?
 
 On Tue, 19 Jun 2007 09:24:38 -0600 Jeffrey D. Smith
 [EMAIL PROTECTED] wrote:
 
 :The compilers at http://www.dignus.com/ allow indirection for options.
 :Just specify a file name (DD name or data set name) in the PARM=
 :string. The compiler reads the file to get the options. Indirection
 :completely relieves the 100-byte limitation issue.
 
 Or you can concatenate a *PROCESS
 
 --
 Binyamin Dissen [EMAIL PROTECTED]

That would be for the HLASM assembler. The dignus assembler supports
*PROCESS statements.

The dignus C and C++ 64-bit compilers support option indirection via
the command line or the PARM= string.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Patents, Copyrights, Profits, Flex and Hercules

2007-06-18 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Dave Jones
 Sent: Monday, June 18, 2007 9:31 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Patents, Copyrights, Profits, Flex and Hercules
 
 As a (very) small ISV (in the z/VM space, not z/OS or VSE), I would be
 much
 more inclined to accept IBM's statements that they feel our pain with
 respect to the problems we are all now having with the PWD program and
 lack
 of small development systems availability if I didn't keep running into
 things like this (from a colleague):
 
 Don't know whether this is a 'news': IBM has made a new z/architechture
  emulator which will run on linux(Intel PC, more precisely as IBM said, a
  ThinkPad/T60 running Suse) and AIX(Power). It requires a USB hardware-
 key
  plugged in to enable the cpu and the total price is about $100. However,
  it's only available to IBMers.
 
 The USB hardware device is an IBM 1090 (a.k.a, the IBM System z Personal
 Development Tool Adapter (zPDTA)), and the software is called the IBM
 System
 z Personal Development Tool (zPDT). It's not Flex-ES and it's not
 Hercules.
 
 So, for about $100, my problems as a small ISV could be solved.wonder
 why IBM isn't interested in making that happen.
 
 DJ


I hope you realize that when IBM provides a $100 mainframe-in-a-box to
its employees, that IBM *owns* the products developed on thoses boxes.

Do you want to give up your intellectual property rights in exchange
for a cheap mainframe development system?

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Patents, Copyrights, Profits, Flex and Hercules

2007-06-14 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Binyamin Dissen
 Sent: Thursday, June 14, 2007 9:15 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Patents, Copyrights, Profits, Flex and Hercules
 
 On Thu, 14 Jun 2007 11:04:28 -0400 Mark Jacobs [EMAIL PROTECTED]
 wrote:
 
 :Bruce Black wrote:
 : Vary true ... There used to be a product (it may still exist for all
 : I know) that was a competitor to IBM's DFHSM
 : ASM2 was eventually acquired by CA and become CA-DISK, then
 : Brightstore CA-DISK, and now CA Disk Backup and Restore.  I think
 : there was an intermediate acquisition that I have forgotten about.
 
 :ASM2 was owned by SKK (The authors of ACF2) and became CA property when
 :CA bought SKK.
 
 Not that I know of (and I worked for SKK at the time).
 
 Cambridge marketed both products.
 
 --
 Binyamin Dissen [EMAIL PROTECTED]

I was employed by Cambridge Systems Group at the time of the takeover by
UCCEL. As it was explained to me by folks there who seemed to know what
was happening, UCCEL wanted to buy only ACF2, but CSG had (semi-)exclusive
marketing rights to ACF2, ASM2, and ADC2. Due to contractual obligations,
if SKK wanted to sell ACF2, then the buyer also had to buy-out the CSG
products (ASM2 and ADC2).

IIRC, some suits showed up on Monday and huddled in a very small room
for most of the week. On Friday, they came out and fired most of the
CSG personnel. The dismissed personnel had to leave immediately; they
could return for their personal items after they attended a meeting
at a local hotel (I think it was called an out-placement meeting). A
local company was hired to handle the dispatching of the fired personnel.

What goes around, comes around. Just about 3 months later CA bought-out
UCCEL, and many UCCEL folks received their pink slips. It seems that CA
was already in private talks with UCCEL for a takeover, but CA had to
wait until the CSG/SKK takeover was complete before CA could proceed
with taking over UCCEL.

I survived the UCCEL takeover, but I quickly went across the street to
Boole  Babbage and got a job there. (Those were the days when MVS
product development jobs were plentifulsigh...)


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Patents, Copyrights, Profits, Flex and Hercules

2007-06-13 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Alan Altmark
 Sent: Wednesday, June 13, 2007 12:07 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Patents, Copyrights, Profits, Flex and Hercules
 
 On Tue, 12 Jun 2007 12:51:12 -0700, Dean Kent
 [EMAIL PROTECTED] wrote:
 
/snip/
 
 No avenue in what way?  PWD allows for Developing Products in addition
 to Current Products.  As long as you're actually in *business* to make
 and
 sell a product (even if your seller is a business partner), PWD is the
 right
 choice.
 
 Alan Altmark
 IBM

With all due respect, PWD has not and will not resolve FLEX-ES issue. There
are many *BUSINESSES* that are dependent on FLEX-ES for their SURVIVAL.

Therefore, we are STILL WAITING for you to say something SUBSTANTIVE about
PWD delivering a cost-effective solution in the ABSENCE of FLEX-ES.

*expletive deleted*

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Patents, Copyrights, Profits, Flex and Hercules

2007-06-13 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Kelman, Tom
 Sent: Wednesday, June 13, 2007 12:16 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Patents, Copyrights, Profits, Flex and Hercules
 
 I believe that one problem with the model below in today's environment
 is the need for strict security.  I've worked in banking IT operations
 all my career.  At one location we gave time on the mainframe to a
 vendor who had some products that plugged into IBM's CPCS (Check
 Processing Control System) in exchange for free use of his software.  I
 don't believe there is any bank that would do that these days because of
 security issues.
 
 Tom Kelman
/snip/

A production system should never be used for developing experimental
software, especially system software. I would expect such an
arrangement to be restricted to a sandbox system with no shared
access to the production system. All data on the sandbox is fake.

At some point, a bank (or any high security site) must bite the
bullet and install the software on its production system and let it
loose. Hopefully, the developer has thoroughly tested the product on
a cloned system and the customer has implemented a back-up/recovery
plan.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: mainframe acces using shared id

2007-06-06 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Rick Fochtman
 Sent: Wednesday, June 06, 2007 10:14 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: mainframe acces using shared id
 
 ---snip-
 We have an issue in one our project. The project is deveopled to see who
 are using the system using the shared mainframe id.
 
  scenario.
 
 1. There are some users who logon to the mainframe using the sharedid
 and common password and do some inquiry going to the cics region. To see
 who are using the sysytem in this way ,we have developed a new screen
 and where the shared users will be entering their individual id 
 individual password , then only the system will allow to enter to the
 application in the cics region.
 
  Problem:
 
 The problem here is that say suppose the user 1 using the shared id and
 common passord login from terminal 1 and after some time while this user
 is logged in , say a user 2 is logging in teminal 2 using the shared id
 and common password , the other user will be automatically kicked out,
 but still the online cics region will be active  for the 2'nd user the
 cics region will not ask their individual password and the new screen
 will not be thrown.
 
 Here there is a security issue/flaw involved. we need to control this
 and this loophole in the design has to be tackled. could some one give
 us suggestion how to take this?
 ---unsnip-
 Using a Shared ID is a seriously bad idea, both from a security
 standpoint AND accountability.
 
 This is the sort of thing that drives auditors screaming to/at management.
 
 Each user should have a unique userid for ALL accesses to any part of
 the system. By using a shared ID, you're allowing a disgruntled
 employee, or former employee, potential access for mass destruction. The
 risks are tremendous; the benefits are nonexistant. Even though the
 users SUPPOSEDLY are only doing inquiry work, a sharp user may know of
 other CICS transactions that are potentially very damaging. NOT WORTH
 THE RISKS!

High security environments are becoming increasingly more common with
recent LEGISLATION requiring security, auditing, accountability. The new
security trend is to prohibit shared-ids and move to multiple ids per
person. Each id has a distinct set of access authorities. If the user
must change hats, then they must change ids. Each id is tied
to a distinct security label that restricts the access authority to
a limited set of resources.

If you want the gory details about RACF Multi-Level Secure
(MLS) operations and security labels, try reading these:

SA22-7683 Security Server RACF Security Administrator's Guide
SG24-6480 Securing DB2 and Implementing MLS on z/OS
GA22-7509 Planning for Multilevel Security and the Common Criteria

I suggest that whatever solution is chosen should be carefully reviewed
for legal compliance.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is there a cost in switching AMODEs?

2007-05-30 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Binyamin Dissen
 Sent: Wednesday, May 30, 2007 11:20 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is there a cost in switching AMODEs?
 
 On Wed, 30 May 2007 09:45:04 -0700 Edward Jaffe
 [EMAIL PROTECTED]
 wrote:
 
 :Binyamin Dissen wrote:
 : Is there much of a cost to switching amodes?
 
 : Is it worth writing code to be able to run completely in 64 bit mode
 (and
 : maintain the top half of the registers) or is it fine to switch in and
 out
 : when referencing storage above the bar?
 
 : POPs does not indicate anything.
 
 :In my experience, excessive switching of addressing mode is quite
 :expensive. I suspect it's because the entire pipeline must be flushed.
 
 I didn't see that in the POPs.
 
 --
 Binyamin Dissen [EMAIL PROTECTED]

A pipe-line flush is usually indicated quite clearly in the PoPs as
a checkpoint synchronization operation.

My PC routines usually set AMODE(64) quite early (after testing FLCARCH)
and stay in AM64, unless a system service, like SETFRR, requires AM31.

Saving and restoring AM64 is quite painless with the linkage stack
(BAKR,PR) instructions.

The LLGT, LLGTR instructions are quite useful for purifying dirty
31-bit pointers.

If you already have clean 31-bit pointers, then using LA Rx,0 is
an easy way to clear the entire 64-bit register before loading the
full word pointer. This paradigm provides backward compatibility to
older 31-bit machines.

Using these techniques, my mainline PC routine code runs in AM64
or AM31 without much dual-pathing. Only the entry logic does some
simple tests and cleans pointers. The remainder of the routine works
correctly in either AM31 or AM64 without any further dual-pathing.

Good luck.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Non-Standard Mainframe Language?

2007-05-27 Thread Jeffrey D. Smith
The C language most definitely *is* a portable assembly language. The
original *NIX compilers actually translated the C source code into
the native platform assembly language. The compilers allowed inserting
raw assembly language, so the programmer could use platform-specific
coding.

Some of the C compilers today translate the C source code straight
into object code, which I despise.

If you want to see a manly C compiler, check http://www.dignus.com/
it generates HLASM output and has special syntactic sugar for
customizing the generated HLASM. It supports 64-bit pointers, access
register mode, inserting raw assembly language statements, referencing
machine registers in C source code, etc.

Even IBM uses Systems/C. IMHO, I think it's far superior to PL/S, PL/X.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Shmuel Metz (Seymour J.)
 Sent: Sunday, May 27, 2007 6:43 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Non-Standard Mainframe Language?
 
 In [EMAIL PROTECTED], on 05/26/2007
at 11:07 AM, Mohammad Khan [EMAIL PROTECTED] said:
 
 Well, C on UNIX is really assembler
 
 No, because it doesn't allow you to generate specific opcodes. Worse,
 its preprocessor facility is far more feeble than that of any
 assembler that I've used for decades.
 
 A similar approach for MVS would have been great in my humble
 opinion
 
 Google for, e.g., BSL, PL/S, PL/X.
 
 --
  Shmuel (Seymour J.) Metz, SysProg and JOAT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: [META] Is !#$%^* spamming entire IBM-MAIN readership?

2007-05-24 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Rick Fochtman
 Sent: Thursday, May 24, 2007 1:18 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: [META] Is !#$%^* spamming entire IBM-MAIN readership?
 
/snip/
 I like the idea of REVENGE. When I get snail-mail prepaid return
 envelops, I make it a
 point to send them back, stuffed with newspaper clippings.

Unfortunately, the old gag of glueing the envelope to a brick doesn't
work anymore. The USPS acquiesced to complaining businesses, and now
they routinely discard the bricks.

/J

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IEBCOPY Unloaded dataset to PC and back again...not successful

2007-05-24 Thread Jeffrey D. Smith
Try using TSO XMIT to the PC. Restore with TSO RECV. XMIT will call IEBCOPY
to unload, then convert the RECFM=VBS into RECFM=FB, which can survive
to the PC and back again. Use binary transfer format.

/J

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of David Day
 Sent: Thursday, May 24, 2007 5:34 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: IEBCOPY Unloaded dataset to PC and back again...not successful
 
 I used IEBCOPY to create a sequentail backup of an ISPF  panel
 library.  I then used IND$FILE to transfer the dataset to my PC.  Thought
 I'd test the backup out by transferring back to the mainframe, and got the
 following when I tried to use IEBCOPY to load the members back.
 
 STEP1COPY  INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT
 IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD)
   009400   1810 180C0100 00CA6D0F 02001810  |  _ |
   009410 0010  00509000 1810 3030200F 7FF8  | 8|
   009420 0020  0D0C000F E5A2 2250 0002006B  |Vs,|
   009430 0030  008F 0080 0F000B08 A912  |z   |
   009440 0040  7F00 80807FF8 8800 0012  | 8  h |
   009450 0050  6A78 1810 0200 9440  |  |   m |
   009460 0060  6AA8 0C0067E8 6AA0 8800  |  |y   Y  |   h |
   009470 0070    0002 3F000900  ||
   009480 0080  0612 20007FF8    |  8|
   009490 0090       ||
 IEB120I SYSUT1   VALIDATION ERROR
 IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64
 BYTES LONG - ACTUAL VALUE IS X'001810'
 
  The IND$FILE for the GET or PUT operation did not specify CRLF as a
 parameter.  Can someone tell me what I did wrong, or if there is a
 'better' way to backup PDS data on a PC.  Thanks.
 
 --Dave Day

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: [META] Is WaveMind spamming entire IBM-MAIN readership?

2007-05-23 Thread Jeffrey D. Smith
I got one today. Found it in my junk email folder, right where it
belongs.

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Shmuel Metz (Seymour J.)
 Sent: Wednesday, May 23, 2007 1:19 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: [META] Is WaveMind spamming entire IBM-MAIN readership?
 
 I just received two e-mails from WaveMind with the subject Need help
 on your IBM Mainframe project?, one addressed to an address that I
 use only for IBM-MAIN. Nothing in the message suggests that it is in
 response to anything specific that I posted. Has anybody else received
 these?
 
 --
  Shmuel (Seymour J.) Metz, SysProg and JOAT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Data Areas Manuals to be dropped

2007-05-14 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Thompson, Steve
 Sent: Monday, May 14, 2007 10:06 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Data Areas Manuals to be dropped
 
/snip/
 
 The following is their [IBM's] official policy and response:
 
 direct quote from ETR
 ACTION TAKEN:
Received following information from Debbie N. (USS ID group).
 ---
 The strategic direction is to remove the data area books (JES2 and JES3
 data areas have already been deleted), and the data areas will be
 generated automatically from the code.  The z/OS USS ID group will look
 into including the missing z/OS USS macros.
 ---
 / direct quote from ETR
 
 If this particular statement of direction sends chills through you as it
 does me, then perhaps you need to make your voices heard.
 
 --
 Regards,
 Steve Thompson
/snip/

A large number of data areas are already documented in the manuals using
programmatically obtained information. The commentary is lifted verbatim
from the macro expansion (possibly using some form of ADATA analysis or
list scraping software).

Although it is an efficient way to gather documentation, the lack of
programming insight (for lack of a better characterization) on how to
use the data area is quite annoying. If it's not written inside the macro,
then it won't appear in the data area manual.

My humble interpretation (meaning it's probably wrong) of IBM's response
is that they intend to stop using technical writers to interpret macro
expansions then translating to a data area manual. Instead, the data area
documentation will be generated exclusively by programmatic analysis of
the macro expansion, and the burden for accurate documentation will fall
upon the macro developers, rather than the technical writers.

2 cents worth. your mileage may vary.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Can FRR prevent ESTAE from seeing registers?

2007-05-13 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Peter Relson
 Sent: Sunday, May 13, 2007 7:51 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Can FRR prevent ESTAE from seeing registers?
 
 Given everything that has been posted, the conclusion is that your best
 chance for keeping things not visible is being disabled. You will then
 not be interrupted and cannot be canceled. The local lock would prevent
 cancels, but not the interrupt cases that Jim Mulder mentioned.
 
 But even with that, there are conceivable non-retryable machine checks
 that
 can occur.
 
 Peter Relson

Unfortunately, I must reference pageble storage. I am using EUT=YES frr.

The fact that MVS has several important storage areas that are
fetchable, like the TCB/STCB/IHSA and linkage stack, leaves several
holes that cannot be plugged.

It's not a huge concern for me, since my product now requires the
client program to be APF-authorized and therefore trusted.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Can FRR prevent ESTAE from seeing registers?

2007-05-11 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Peter Relson
 Sent: Friday, May 11, 2007 5:28 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Can FRR prevent ESTAE from seeing registers?
 
 Only by retrying.
 
 If you cannot retry, it is your responsibility not to put things into
 registers if they are sensitive in nature (not that that is necessarily
 particularly feasible).
 
 Peter Relson

If I have a non-empty FRR stack, will DETACH or CANCEL processing defer
until the FRR stack is empty?

When I have sensitive information in the general registers, I am not
vulnerable to an access exception (all client data has already been
copied to my protected storage areas).

When I am vulnerable to an access exception for client storage, I do
not have sensitive information in the general registers.

Thus, the only situation that worries me is DETACH or CANCEL interrupting
me when I have sensitive information in the general registers; I have an
FRR defined at that time. Will the DETACH or CANCEL defer until I delete
my FRR?


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Top 10 software install gripes

2007-05-11 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Ted MacNEIL
 Sent: Friday, May 11, 2007 10:37 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Top 10 software install gripes
 
 There, I feel better.
 
 What are you really trying to say?
 You have to stop holding back and be more direct as to what you truly
 mean!

That's right. Don't sugar-coat it. Tell it straight!

/J

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: OT - The antikythera mechanism

2007-05-11 Thread Jeffrey D. Smith
I thought the abacus was the earliest known computing device.

/J

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of john gilmore
 Sent: Friday, May 11, 2007 12:09 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: OT - The antikythera mechanism
 
 Pp. 94-102 of this week's New Yorker, that of 14 May 2007, contain an
 article by John Seabrook, Fragmentary knowledge: Was the antikythera
 mechanism the world's first computer?, that will richly repay the
 attention
 of anyone interested in this mechanism.
 
 John Gilmore

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Can FRR prevent ESTAE from seeing registers?

2007-05-10 Thread Jeffrey D. Smith
Greetings,

I have an FRR that erases sensitive material from storage areas before it
percolates an ABEND. I also want to erase the registers so that any ESTAE
that may get subsequent control cannot see the error-time registers. I
want the ESTAE to see zeroes in its SDWA.

The error-time registers may also have sensitive material that I don't
want exposed to a user program that is using my service routine.

Is there a clean (IBM supported) way to achieve this?

Thanks in advance.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Can FRR prevent ESTAE from seeing registers?

2007-05-10 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Craddock, Chris
 Sent: Thursday, May 10, 2007 11:11 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Can FRR prevent ESTAE from seeing registers?
 
  I have an FRR that erases sensitive material from storage areas before
 it
  percolates an ABEND. I also want to erase the registers so that any
 ESTAE
  that may get subsequent control cannot see the error-time registers. I
  want the ESTAE to see zeroes in its SDWA.
 
  The error-time registers may also have sensitive material that I don't
  want exposed to a user program that is using my service routine.
 
  Is there a clean (IBM supported) way to achieve this?
 
 AFAIK you can just scribble on the SDWA. What ever you leave there is
 seen by subsequent error recovery exits of the same class.
 
 See
 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A800/18.
 2.2.2?DT=20010118152433#HDRSDWAUSE
 
 or http://tinyurl.com/2rwe2f
 
 I am not completely certain that also applies for FRR percolation back
 to a non-FRR routine. But it -IS- documented that SDWACOMU is copied
 from one SDWA to the next, so you can definitely use SDWACOMU to pass
 footprint info from an FRR to a non-FRR environment.
 
 So if you always conspire so that the top of the non-FRR recovery chain
 is one of your own recovery exits, you can have that exit notice your
 private footprint information in SDWACOMU and do whatever you want with
 the SDWA that gets passed along when you percolate. Kinda messy, but
 effective.
 
 CC

Sigh... I am writing a service routine called by clients that must not
see the error-time registers. The SDWA is completely reallocated for
the transition between FRR and ESTAE processing, with only the SDWACOMU
copied to the new SDWA from the old SDWA. However, the client won't care
about that field. The client ESTAE routines are not mine.

My FRR is established under a stacking PC routine. I cannot use an ARR
to muck with the SDWA, because RTM will reallocate the SDWA upon
subsequent percolations due to storage key changes. My ARR will get a
key zero SDWA. Subsequent client ESTAE routines get a key 8 SDWA.

Sigh...again.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: jcl.

2007-05-08 Thread Jeffrey D. Smith
Another possibility is to use a post-processing step (TSO REXX or CLIST)
that renames a hard-coded data set name to the name you really want.

READ-ONLY would be covered by your security product, like IBM RACF,
to protect the data set under a generic profile (perhaps).

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Lizette Koehler
 Sent: Tuesday, May 08, 2007 11:37 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: jcl.
 
 As some have pointed out, there is no Dynamic symbol resolution in MVS for
 Date.  You have to use one of several processes,
 
 However, if the JCL is an STC, there might be the ability to you a SYSTEM
 symbolic - YYMMDD, but it only works for STCs.  It will not work for
 regular JCL (AFAIK).
 
 Otherwise,
 
 REXX or CLIST process
 Scheduler Software
 Manually code it in the JCL
 
 No other options that I know about.
 
 Lizette
 
 
 Yes that is correct, sory for the type error. Please let me know is this
 can be done thru jcl other than rexx
 
 Lizette Koehler [EMAIL PROTECTED] wrote:  Oh, and I forgot one
 IMPORTANT element.
 
 JCL will not ALLOW the use of all numbers as a qualifer. You would need
 to specify
 
 userid.test.D050807
 
 userid.test.05082007 Will have a JCL failure.
 
 Lizette
 
 
 Raj,
 
 Only way is through a Scheduler Product (Control-, Jobtrace, CA-11) or
 build a REXX/Clist to submit the JCL after it is built.
 
 As for Read Only - that would be the actions of your security (Top
 Secret, ACF2, RACF)
 
 Lizette
 
  I need one help, could some one please let me know how this can be
 done . We need to create a file name appended with the current date
 dynamically ie if we ran today the file has to created like the below
 
  userid.test.05082007
 
  Could some one also let me know is there any way by which the created
 file is made read only.
 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: jcl.

2007-05-08 Thread Jeffrey D. Smith
My interpretation of the OP request for read-only was to prevent
anyone from writing to the data set. How do you enforce subsequent
allocations (by other jobs or users) to specify LABEL=(,,,IN)?

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Ted MacNEIL
 Sent: Tuesday, May 08, 2007 12:41 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: jcl.
 
 READ-ONLY would be covered by your security product, like IBM RACF, to
 protect the data set under a generic profile (perhaps).
 
 Check the JCL Manual:
 
 LABEL=(,,,IN)
 
 File will be read-only, regardless of what you attempt.
/snip/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Counting occurrences of a string in loadlib

2007-04-27 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Tom Marchant
 Sent: Friday, April 27, 2007 7:44 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: RES: Counting occurrences of a string in loadlib
 
 On Fri, 27 Apr 2007 10:14:55 -0300, ITURIEL DO NASCIMENTO NETO
 [EMAIL PROTECTED] wrote:
 
 Ira,
 
 Try copying one of these PDSs (IEBCOPY - COPYMOD) to a new one with the
 other blksize, and then proceed with your compare step.
 
 Still might not work.  Unless you can guarantee that each member starts at
 the same location on a track, you will likely have blocks in one PDS that
 are
 different sizes than the blocks in the other.
 
 If a large load module starts on a new track, you'll have a 32K block at
 the
 beginning of the track, then a shorter block at the end.  If the same load
 moule starts after a member that ends with a 32K block at the beginning of
 a
 track, it will start with a smaller block, then have a 32K block at the
 beginning
 of the next track.
 
 --
 Tom Marchant

What about some technique for unloading both PDS (either IEBCOPY or
IEHMOVE) to sequential files, then comparing the sequential files? IEHMOVE
is very slow, but it unloads in collating sequence to 80-byte records. If
both PDS is logically the same, then the IEHMOVE output should compare the
same?

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Latest Principles of Operation

2007-04-26 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Edward Jaffe
 Sent: Thursday, April 26, 2007 9:45 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Latest Principles of Operation
 
 Clark Morris wrote:
  The frustrating thing is that there is no compiler switch to tell most
  of the compilers that these instructions can be used because the
  target is known.  ISV's normally have to hang back on using these
  instructions because the target processor may not have the
  instruction.
 
 
/snip/
 
 ISVs do indeed have to hang back. And, so do IBM developers. The life
 saver is knows as an Architectural Level Set. Some customers don't
 like them because they tend to obsolete affordable hardware processor
 models. But, IBM and ISV developers like them because they allow use of
 the new facilities. For example, IBM no longer supports anything less
 than z/OS 1.6. And, z/OS 1.6 requires z/Architecture. This means that
 IBM developers can use z/Architecture instructions for _all_ new code
 targeted for z/OS without the need for dual-path, bifurcated, or lowest
 common denominator instruction paths. The same holds true for any ISV
 that follows IBM's support schedule.
 
 --
 Edward E Jaffe
/snip/

Unfortunately, there are still some customers (at least one that is a
big name in the corporate banking world) that uses a 31-bit Amdahl
box with OS/390 R10. I had to write my crypto stuff using some dual
pathing to accommodate them. sigh...

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Laugh, laugh. I thought I'd die - application crashes

2007-04-17 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Craddock, Chris
 Sent: Tuesday, April 17, 2007 9:17 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Laugh, laugh. I thought I'd die - application crashes
 
  As IEFBR14 is a frontend to SVC 99 (allocation), SVC 13 (abend) is the
  frontend to RTM.  It's a way to stop things in their tracks when fubar
 is
  detected.
 
 IEFBR14 is a front-end to allocation Wow! Who knew?

In a former life many many years ago, I was a sysprog at a big utility
company. When we migrated from MVS/370 to MVS/XA, the COBOL programmers
were in a panic. They all wanted to know whether IBM would continue to
support IEFBR14 under the new MVS/XA. They were the same programmers
who were clearly undecided about voting for a stock split, because it
would mean a lot of extra work for them to change all of the hard-coded
constants for the number of outstanding stock shares.

Sigh...those were the days...

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: ICSF on z890?

2007-03-26 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of McKown, John
 Sent: Monday, March 26, 2007 7:46 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: ICSF on z890?
 
  -Original Message-
  From: IBM Mainframe Discussion List
  [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gillis
  Sent: Sunday, March 25, 2007 3:55 PM
  To: IBM-MAIN@BAMA.UA.EDU
  Subject: Re: ICSF on z890?
 
 
  McKown, John wrote:
/snip
 
  Do you have the CSF started task running? I am running that on a z890
  without crypto coprocessors.
 
  Paul Gillis
 
 Yes, I do. It starts with the messages:
 
 CSFM101E PKA KEY DATA SET, TSSTV.CSF.PKDS IS NOT INITIALIZED.
 CSFM100E CRYPTOGRAPHIC KEY DATA SET, TSSTV.CSF.CKDS IS NOT INITIALIZED
 .
 CSFM507I CRYPTOGRAPHY - THERE ARE NO CRYPTOGRAPHIC COPROCESSORS
 ONLINE.
 CSFM508I CRYPTOGRAPHY - THERE ARE NO CRYPTOGRAPHIC ACCELERATORS
 ONLINE.
 CSFM001I ICSF INITIALIZATION COMPLETE
 CSFM400I CRYPTOGRAPHY - SERVICES ARE NOW AVAILABLE.
 
 I think that I now need to initialize the PKDS and CKDS, but I cannot
 figure out how. I go into the ICSF menus in ISPF, but almost all of them
 say OPTION NOT AVAILABLE. Yes, I do have all the RACF work done and I
 think it is correct.
 
 --
 John McKown

Greetings,

FWIW, it appears that the hardware is offline. Without the hardware,
ICSF cannot initialize the data sets, because it needs the master
key authentication pattern that is contained within the crypto secure
boundary. That's as far as my thinking goes on this.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Data Spaces or Hiperspaces

2007-02-27 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of David Day
 Sent: Tuesday, February 27, 2007 4:17 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Data Spaces or Hiperspaces
 
 I have no experience with Hiperspaces, but have coded data spaces on a
 number of occasions.  If you're going to play by the rules, the data space
 is tied to the address space that creates it, so if you do this, you have
 to
 keep the address space that does the create around.  Other than that, you
 have to have a mechanism for making the alet of the data space available
 to
 these other address spaces when they need it.
 
 --Dave Day
 - Original Message -
 From: Tom Savor [EMAIL PROTECTED]
 
  Is this possible or feasible from an Batch application standpoint ??
 
  1). Build data (create) into a Data Space or a Hiperspace in 1 Batch
 job.
  2). Access this data in many following Batch jobs.
  3). At the end of Batch cycle, delete #1's Data Space or Hiperspace.
  If possible to do, then which is perferable ??  Data Space or Hiperspace
  ??
 
  Any examples ??
 
  Thanks,
 
  Tom Savor

Playing by the rules means that the data space is deleted automatically
when the owning task terminates. This usually means at end of job step
all data spaces created by the application are gone. If your application
is running authorized (supervisor state key zero), then you can create a
data space and hang it onto a higher level task in the address space.
However, getting addressability to the data space is problematic, because
of the way the PASN-AL (Primary Space Access List) is handled across job
step tasks.

Hiperspaces are usually used for windowing onto the files (VSAM?), but I
don't recall at the moment the gory details. If you want data persistence
across job steps or jobs, then you want a data set and probably want to
use a hiperspace for a window onto the file.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: License keys for ISV products(What alternatives are there?)

2007-02-25 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Dave Salt
 Sent: Sunday, February 25, 2007 10:47 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: License keys for ISV products(What alternatives are there?)
 
 From: Ted MacNEIL [EMAIL PROTECTED]
 1. Vendor delivers key.
 2. Key cannot be installed until the upgrade.
 
 Why? If the product is designed properly, you should be able to specify
 more
 than one key. If the first key fails, the product tests the second key
 (and
 so on) until a working key is found. This allows you to install keys way
 ahead of time (e.g. long before cutting over to a new CPUID). SimpList
 allows up to 3 keys; a number of other MacKinney products allow up to 6.
 
 Dave Salt

Even in that scenario, how do you know that the key for the new CPUID
will actually work when the CPU is upgraded? There should be some kind
of key test mode thing to be sure the key will work on an anticipated
CPUID.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


z/OS developer jobs (was: Literacy)

2007-02-20 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Sam Golob
 Sent: Tuesday, February 20, 2007 8:25 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Literacy
 
 Hi Folks,
 
Throughout my career, I was always outside of IBM, except for one
 short period, when I worked as a consultant at IBM to relieve the Level
 2 queues.  At that time, IBM was training its Level 2 people out of
 college on ONE or (maybe) TWO components of MVS, for 18 months, to get
 them up to speed.  I don't know if any of those trainees ever got to see
 a real data center.
 
When IBM hired us as consultants, we were up and working with ONE
 WEEK's training.  See the difference between one component people and
 generalists?  IBM knew that when they hired us.  They only got us
 because (at that time) it was a bad time for regular sysprog jobs, so
 they had a pool of unemployed sysprogs to draw from.
 
Just an observation to show (again) that knowledge pays.
 
While I am on this subject, I want to throw in a comment about MVS
 developers (who are also highly trained and knowledgeable).  If you have
 your own (low budget) software company, FLEX-ES (and the ADCD program)
 have (until now) provided a way for developers to use their skills to
 write good system utilites that improve the usability of z/OS.  Unless
 IBM themselves provide us with their OWN good emulator and an affordable
 low-end hardware solution, THEY will be up the creek as well as us.
 Don't they know that?  Do they secretly have their own S/390 emulator in
 the works?  Otherwise, it would look like they are abandoning a large
 component of the MVS (and VM and VSE) support structure.
 
 Sincerely,   Sam

I, for one, have just about thrown in the towl with respect to finding
employment (either regular or contract) as MVS/OS390/zOS product developer.
Forget about the so-called open systems jobs, like Java or Windows,
software development. My last job interview in that line of work was a
rude awakening; it was obvious after 10 minutes that they were looking
for someone younger and prettier (i.e., not a dinosaur), and definitely
looking for someone they could pay not more than $40K/year. I had a similar
experience a few years ago when I interviewed at that big employer up in
the Seattle-Tacoma area, where all the young employees had private offices
and the older employees were driving the shuttle buses. eek!

Now that FLEX-ES is all but history, a small-time z/OS developer like me has
no choice but to change careers with no safety-net. If any of you are in
the same boat, I sincerely wish you the best of luck.


Cheers

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: License keys for ISV products(What alternatives are there?

2007-02-20 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Bruce Black
 Sent: Tuesday, February 20, 2007 12:14 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: License keys for ISV products(What alternatives are there?
 
 
  Possibly the only way to bring these A-P departments into line is to
  have a notice in the invoice that says failure to pay promptly means
  that the product will stop working.
 Then the invoice should specify immediate payment, not net 30 or
 whatever.
 
 --
 Bruce A. Black

It's a bit hazy now, but from my recall of my accounting class in college,
net 30 means full payment is due within 30 days, not after 30 days. Many
A-P departments now interpret it as postmarked on day 30, so they get
another 7 days (or so) float from snail mail.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: License keys for ISV products(What alternatives are there?)

2007-02-18 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Rick Fochtman
 Sent: Sunday, February 18, 2007 11:20 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: License keys for ISV products(What alternatives are there?)
 
/snip/
 Vendors have an obligation to their shareholders to protect their
 intellectual property, and try to limit liability in case of abuses; I
 can accept that. But let's face it, some vendors' pricing practices are
 downright PREDATORY.  First they hook you into using their products,
 then impose unconscionable price increases after the so-called
 introductory period. In my personnal experience, one vendor sent 9
 marketting reps to my office, when all I had requested was a copy of the
 proposed contract, which could have been FAXed to me! Bloated marketting
 staff with nothing to do; I'm sure other areas of staff are similarly
 bloated; all these things contribute to high prices and loss of
 fexibility. Compuware built a nice shiny new headquarters building in
 downtown Detroit, then promptly laid off 5,000 people to cut costs.
 
 Too many pencil pushers and not enough technicians!

Now you're starting a different subthread. Keys to protect intellectual
property have not much correlation with the pricing model. Usage-based
pricing model is for leased software, not purchased software (like
M$ Excel).

There is a huge difference between leased versus purchased software
licensing models.

Purchase software, like M$ Excel, generally have limitations on upgrades,
operating system, and support life (bug fixes). You pay once, and get
bug fixes on a somewhat timely basis until end of support. Installing
the software phones home and identifies itself to be sure that the
particular serial-numbered software is not already installed elsewhere.
This is a reasonable way to protect against piracy, but it may be a
problem for some mainframe sites that want to be isolated from the
outside world.

Leased software, like much of the mainframe software out there, has
some kind usage-based pricing that hopes to correlate the cost of the
software to the benefit received. The customer receives bug fixes,
new versions, and support for newer operating systems. If the customer
does not perceive the benefit as being greater than the cost, then
the customer stops paying and the product stops operating. Most CFO's
use the concept of a hurdle rate that specifies the rate of return
on any investment. The benefit must exceed a certain multiplier applied
to the cost of the investment.

Usage-based pricing has many challenges. Is it per user, machine capacity,
or per transaction (i.e., metered usage). If it is metered usage, how
is the usage measured and reported (e.g, intrusiveness and accuracy are
primary concerns). If it is machine capacity, how to accommodate periods
of low activity versus high activity (end of quarter and end of year
processing)? If it is per user, how quickly can the ISV accommodate
changes in user quota?

The notion of using dongles (a hardware device with a programmatically
accessible serial number) is one way to assure that the software is
running on the correct machine. The mainframe CPU serial number serves
the same purpose. The MAC address for a network card also serves the
same purpose, but is harder to verify programmatically on a mainframe.

All of the concerns and issues mentioned above must somehow be
distilled into a license key implementation that does not add
unnecessarily to the sysprog burden.

I understand that customers don’t want to become dependent on
leased software that expires and shuts down during critical times.
However, there must be some reasonable cut-off point when negotiations
break-down at contract renewal time. If the customer and vendor cannot
agree on a new contract, then the product must stop operating. Where
will you draw the line; 30 days, 60 days, 180 days, more? How long will
customer get a free ride on a mission-critical ISV software? Until a
replacement can be found or built? Does the contract allow for defaulting
to month-to-month fees until a new long-term contract is negotiated (or
the customer has gotten past their critical end-of-quarter processing)?
What if there are no acceptable replacement products and the customer
is unable or unwilling to build their own replacement? Disaster recovery
on unknown machines (why are they unknown?) is a big issue.

Many license key implementations are awkward and difficult to manage.
Complain to the ISV and be specific about the issues. Pricing models
are entirely a different matter that have little correlation to the
license key implementation. Let's be clear in this topic when discussing
pricing models versus license key implementation. License keys are never
going away. However, bad implementations should go away.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484

Re: License keys for ISV products(What alternatives are there?)

2007-02-17 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Ed Gould
 Sent: Saturday, February 17, 2007 8:03 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: License keys for ISV products(What alternatives are there?)
 
 On Feb 17, 2007, at 1:55 PM, Ted MacNEIL wrote:
 
  Not all products are like that. Maybe then the issue isn't so much
  that keys are required, but the way they're sometimes implemented
  by the vendor?
 
  Sometimes? -- all the time. No vendor, that we use, has made keys
  easy to use!
 
 
  If keys were always received well before the old ones expired, and
  all you had to do was enter them in a flat file, would that be a
  big deal?
 SNIP--
 
 This is a more of a what if issue but I have seen it happen in the
 real world.
 
 I have seen a system frozen no updates allowed for *any* reason.
 The license expires (my memory says it was a CA product but its
 immaterial) what does one do?
 
 Ed

Couple of ideas pop:

1.  Reclassify license refresh as a non-update.

2.  Connect the production system to the outside world and let the
ISV product talk to the ISV website server thing to verify license
and dynamically update the license (e.g., call home).

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: The quantum computer comes of age

2007-02-06 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Paul Gilmartin
 Sent: Tuesday, February 06, 2007 9:23 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: The quantum computer comes of age
 
 This is the sort of hype to potential investors and customers that
 I take cum grano salis.
 
 But it might be real.
 
 -- gil
 --
 StorageTek

I was thinking they should've scheduled it on April 1.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: LPAR Org Security

2007-02-05 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Jeffrey Deaver
 Sent: Monday, February 05, 2007 4:17 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: LPAR Org  Security
 
 The question I'll get to:  How are your shops organized when it comes to
 LPAR organization, access and security?
 
 To explain where I'm coming from:
 
 1) LPARS
 We have two.  PROD supports everything from TSO users and program
 development to multiple instances of IMS and DB2 and batch processes.
 TEST2 is an exact image of PROD created with volume level snapshots and is
 used for testing upgrades and troubleshooting issues.
 
 2) Networks
 We have two.  Production, of course, has most things connected to it,
 including the PROD LPAR, and all the other production servers in the
 company.  It also has a ton of development and QA servers connected to it,
 along with the TEST2 LPAR when we want it there.
 The other network is called NEQAL, and is our separate testing network.
 We
 dynamically build pieces of our production environment there when we want
 to test upgrades and changes before we do it on the production network.
 The TEST2 LPAR is sometimes connected to this network when the testing
 there needs to involved the mainframe.
 
 With that explained, we've recently had a security question come up.
 
 Should the TEST2 LPAR only be connected to the NEQAL network?
 
 You see, this would then force a user to use a workstation in a separate
 location, not at their desktop, in order to perform work on TEST2.  In
 this
 way, then, the possibility of someone becoming confused about which LPAR
 they are looking at on their desktop is minimized.  In other words, I,
 systems engineer, would be less likely, as an example, to stop TCPIP
 accidentally on the PROD LPAR because if I'm sitting at my desk, I know
 its
 the PROD LPAR, and if I'm in the NEQAL lab, I know its TEST2.   Right now,
 I can swap from PROD to TEST2 at my workstation.
 
 We systems engineers are, of course, arguing that we need that access as a
 matter of productivity.   It really opens a can of worms, since if they
 were to dictate that, we would soon be arguing that all the development
 and
 test servers should also only be on the NEQAL network.  And then we get
 into the arguments about where the production instances of DB2 verses the
 3
 test instances should be running.  Separate LPARS?  Ug.
 
 So the main question I want to ask you all is this:   How are your shops
 organized when it comes to LPAR organization, access and security?
 
 Most of us have only worked in our own shop, and so learning what others
 do
 will help us decided which course of action is best - and convince
 management of it!
 
 THANKS!
 
 Jeffrey Deaver, Engineer

Just to muddy the waters further, I would suggest looking into elevating
the security controls on the production and test systems to use RACF
security labels. Make the default security label for your TSO systems
engineers match the test system security label. In order to muck with
the production system, you must log-on and explicitly specify the security
label for the production system. Ensure all privileged or authorized
commands and access procedures are protected by the appropriate security
label. So, if you logged onto with the default security label, you won't
have the authority to issue production system commands; only test system
commands are available. If you try to log-on to a test system with a
production system security label, RACF will reject the log-on.

I am not a RACF expert.
Two cents worth. Your mileage may vary.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Cross Memory and AR ASC Mode

2007-01-26 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Peter Relson
 Sent: Friday, January 26, 2007 5:36 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Cross Memory and AR ASC Mode
 
/snip/
 
 Jeffrey Smith mentioned LASP: I hope it isn't surprising to anyone that
 you
 are not supposed to use that instruction, just as you are not supposed to
 do all sorts of things provided for the base OS to use in order to make it
 possible for your applications to run (including such obvious things as
 using LCTL to set various things).
 
/snip/
 
 Peter Relson

Just to be clear, I mentioned LASP as one of the many instructions intended
for the operating system to use for preparing a unit of work for dispatch.
When a unit of work is suspended, its current primary and secondary ASN are
saved somewhere and later restored with LASP (or equivalent). A similar
function may occur when popping a PC state entry with the Program Return
(PR) instruction. Either way, before the advent of ASN-LX-REUSE-FACILITY,
(ALRF), there was no way to know for sure whether the ASN was the same
logical address space that was bound to the unit of work at suspension.

Setting secondary addressability (SSAR) to an arbitrary space clearly
violates system integrity rules. On a sandbox system intended to crash
and burn, who cares? On a production system, it's clearly a no-no, but
I would guess there are still some ISV products being used on production
systems, which violate system integrity rules in a variety of ways,
including inappropriately referencing arbitrary address spaces, elevating
authorization for a unit of work running in an insecure environment, using
problem key storage in the common area, the list goes on and on. I've seen
all kinds of such shenanigans and I was slapped down by management when I
complained. (But I'm not bitter about iteek!)

Two cents worth. Your mileage may vary.

Cheers
Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Cross Memory and AR ASC Mode

2007-01-26 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Clark Morris
 Sent: Friday, January 26, 2007 6:18 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Cross Memory and AR ASC Mode
 
/snip/
 
 What are the security implications of allowing uninvited snooping?  Is
 this a good way to pick up confidential information if someone
 understands the application?  How does Omegamon handle this and can
 the method used be made available assuming the security concerns are
 met?

By definition, an authorized program is a trusted program. It can do
whatever it wants and is presumed to maintain the confidentiality of
any application data that it sees.

Placing a program into an APF library is a management policy decision,
not a technical issue. If management trusts the author of the program,
then let the system security adminstrator and systems programmer put it
in the APF library and let it do its thing. Otherwise, just say no.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: SVCs

2007-01-25 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Edward Jaffe
 Sent: Thursday, January 25, 2007 8:52 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: SVCs
 
 Craddock, Chris wrote:
  So... SVCs are for dopes. PeeCees rool!
 
 
 Great info! (Of course! That's why they pay him the big bucks.)
 
 This is one significant difference between SVC and PC routines that I
 haven't heard anyone mention yet. PC routines are associated with an
 address space service provider whereas SVC routines are not. Of
 course, it's possible to give SVC-like qualities to PC routines by
 making them appear to be independent of any restartable address space
 (e.g., connect them to your own space every time, connect them to a
 system address space that can't be restarted, etc.).
 
 Just something else to keep in mind ...
 
 --
 Edward E Jaffe

Yes, I've heard of some folks hacking into the MVS-owned portion
of the PC entry table, looking for an empty slot (which points to
a generic ABEND routine for a bad PC number) and replacing the
entry table entry (ETE) with their own stuff. Usually, the slot is
owned by PCAUTH or some other system address space that cannot shut
down without MVS grinding to a halt. I don't like that approach at
all, but I can see where it may be of value on a sandbox development
system that is intended to crash-and-burn at any time. For a production
system, I would always use a server space with appropriate runtime tests
and recovery routines in case an operator accidentally cancels the
server space. A nonswappable server space that doesn't consume significant
CPU cycles is cheap. The client spaces get charged for the CPU time while
in the PC routine, which is a good thing, IMHO.


Two cents worth. Your mileage may vary.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: SVCs

2007-01-24 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Rob Scott
 Sent: Wednesday, January 24, 2007 10:48 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: SVCs
 
 Also keep in mind that z/OS provides elegant controls as to which
 address space can use a specific PC routine.
 
 For example, your server could supply a System LX PC routine that
 performs some sort of SAF check on the caller before it performs the
 AXSET and ETCON to allow the address space to issue other non-System LX
 PC routines.
 
 
 Rob Scott
/snip/
I am a big proponent of dual LX. A system-LX for non-space switch routines
that validate/verify/whatever and then connect to non-system-LX space-switch
routines for the main processing. It avoids the non-reusable ASN syndrome
in most cases.

I am still warming up to the new fangled wide LX thing ALRF
(ASN-LX-REUSE-FACILITY).

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: ISPF edit bug

2007-01-23 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Kirk Talman
 Sent: Tuesday, January 23, 2007 10:47 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: ISPF edit bug
 
 I have a small but irritating bug that I do not yet have a fix for.
 
 When in ISPF edit and using hardware tabs, one can place the cursor on a
 tab and press enter.  The tabs on that line are cleared so one can place a
 character where a tab was.
 
 I find when editing for long periods that instead of clearing the tabs on
 the line on which the cursor is placed, the tabs on the line above are
 cleared.
 
 Problem is not reproducible in the sense I know what will make it happen.
 
 Problem may have happened under 1.3 but we are now:
 
 z/OS 01.07.00
 ISPF Level 5.7.0
 harware is various 2064, 2084, 2094
 
 Has anyone ever seen this?

Are you using a true greenscreen terminal or a terminal emulator?

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Decoding the encryption puzzle

2007-01-19 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Jeffrey Deaver
 Sent: Thursday, January 18, 2007 6:44 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Decoding the encryption puzzle
 
 I wouldn't encrypt data within a datacenter. The only data that gets
 encrypted around here is data that goes out the door. Internal tapes are
 not encrypted.
 
 If one level of backup are in your automated tape library, in a data
 center
 with card-key access in a building with armed guards on all entrances who
 inspect packages coming in AND going out, then I don't think you need to
 encrypt that data.
 
 Its too easy for one of those 'secure' tapes to walk out the door with a
 disgruntled employee.  And when the audit turns up a tape missing - its
 not
 going to care how or where it went - only that its missing and not
 encrypted.  More than once I've read notices from companies announcing
 breaches where they state that they are '99% sure its in a landfill,
 but...'.  And while that may be true and the data is more than likely
 safe,
 the damage to the reputation is already done, and the cost to notify is
 real.
 
 For my money, if it can be carried out, its going to be encrypted.
 
 Jeffrey Deaver, Engineer

My favorite management quote, We have never had an undetected security
breach.

There are US government publications describing so-called best practices
for securing data and managing keys, which also describe themselves as
evolving documents. That is, they are still inventing the processes
and updating the publications as new ideas are introduced.

If your datacenter is highly secure, that means both physical security
and data security (encrypted). Data is accessible only through a trusted
server that authenticates the user's security permissions (e.g., RACF
security label of the data and of the user). Permission to access
clear data is distinct from permission to access encrypted data (usually
for archival/restore purposes). Permission to read-only is distinct
from permission to read-write. The front-end application never sees
both encrypted and clear data at the same time; it's managed within a
secure boundary of a trusted server.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Decoding the encryption puzzle

2007-01-18 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Hal Merritt
 Sent: Thursday, January 18, 2007 10:49 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Decoding the encryption puzzle
 
 There I was, looking into the teeth of a serious ice storm, any my
 company laptop dies. I have a generator and satellite telecom so that
 part was covered. But the laptop was a single point of failure between
 me working from home or risking life and limb having to go out in the
 storm. The prospect of driving over roads covered with ice and idiots
 gives me gas.
 
 The failure was in the encryption software.
 
 The techs tell me the encryption software has been almost trouble free.
 Almost. And failures are rare. But they happen. When there is a failure,
 they can almost always recover the data. Almost.
 
 I don't have any numbers, but my sense is that only one of a hundred
 laptops have suffered data loss. One percent.
 
 Now, laptops pose an extraordinary level of risk and some hard nosed
 encryption is arguably mandatory. That is not the point of this rant.
 
 Is it possible that mainframe encryption can guarantee perfection? Or
 will we see about the same thing: loss of one percent of the most
 mission critical data in the shop? Or one in a hundred critical
 datasets?   Is the mitigated risk worth the loss?
 
 Gives this old sysprog pause.
/snip/
Encryption software failing is somewhat vague. Did the software
generate incorrect cipher text? Did the software incorrectly
decipher the data using the correct key? Was the key lost or stolen
or exposed or improperly expired?

Symmetric (secret) key encryption, like DES or AES, is very reliable
with respect to correct encipher/decipher operation. The main issue
is key management: How to generate strong keys, securely store those
keys, and associating the keys with the protected data? It all boils down
to having a clear master key somewhere that unlocks all of the other
keys. Even the IBM hardware encryption with tamper-resistant master key
protection needs to be reset sometimes. That means the master key (or
the pass phase used to generate a master key) must be written down somewhere
(and physically protected) so that the security administrator can re-enter
it into the hardware. Without the central master key, all other keys are
inaccessible (not decipherable) and thus the encrypted data is unavailable.

Asymmetric (public/private) key encryption is only viable for exchanging
encrypted symmetric keys, because the algorithm is computationally
intensive and far too expensive for high volume encryption traffic.

Physical deterioration of encryption silicon may occur over time, just
like deterioration and failure of main memory or logic circuits or hard
drives. That's why encryption devices self-test with known answers and
internally check their results.

I've heard that some hardware encryption devices may perform the
encryption 3 times per block of data and compare the results for a
perfect match. The process is repeated until a perfect match of
the 3 results or until a time-out occurs (machine check interrupt).

A properly designed encryption device will detect bad results and
not expose incorrect results outside of its secure boundary. I don't
worry about the bitwise accuracy of encrypt/decrypt results. I worry
about key management, because it's the central point of failure. If
your keystore is on a harddrive that fails, then all data encrypted
by those lost keys is inaccessible.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: CPACF Metrics?

2007-01-17 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Jeffrey Deaver
 Sent: Wednesday, January 17, 2007 12:58 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: CPACF Metrics?
 
 I've been told that IBM publishes some numbers that show CPACF overhead
 metrics somewhere? Anyone know where?   I'm basically interested in
 confirming something a vendor told me about an encryption product - so
 many
 MBs encrypted for so many CPU seconds.
 
 Thanks.
 
 Jeffrey Deaver, Engineer

I found some timings in this pdf document. It is for z/890.
http://www-900.ibm.com/cn/products/servers/zseries/security/downloads/Web_z8
90_Crypto_07282004.pdf

Watch out for the wrap.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Mainframe jobs list?

2007-01-17 Thread Jeffrey D. Smith
Greetings,

What you all recommend for the better jobs lists for mainframe developers?
(Yes, I am looking for employment.)


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is anyone still running..........................

2007-01-11 Thread Jeffrey D. Smith
 -Original Message-
 
 Given the global nature of this list I was curious if any list members
 were
 aware of any financial organization(s) still running Os/390 V2.10 and/or
 still running on G5/G6 processors.  Nice to hear all comments but mainly
 interested in the financial sector.
 
 Regards
 James F. Smith

As of about 1 year ago, a USA-based check printing company was still
running their production on an Amdahl box with OS/390. My encryption
product had to tolerate 32-bit architecture specifically because of
that prospective customer.

If it ain't broke, don’t fix it. Their applications were running
satisfactorily, so their management had no motivation to upgrade
to 64-bit architecture.

p.s.: I still order my checks from them.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Just another example of mainframe costs.

2007-01-06 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Rick Fochtman
 Sent: Saturday, January 06, 2007 11:09 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Just another example of mainframe costs.
 
/snip/
 I used to keep System Message and System Codes in large three-ring
 binders on my desk. I also made sure that other groups had multiple
 copies of both manual sets in their areas for reference. When a
 programmer came to me the first time with a message, we'd look it up
 together. The second time he came to me with the same message, I'd hand
 him the binder; the third time I dropped it on his feet. Not at, but
 ON his feet. My point was that he should at least look it up and make
 some attempt at understanding what it meant. If the message wasn't
 understood after looking it up, then I'd work with him/her. But they had
 to at least make the attempt. Is that an unreasonable approach? Some of
 the organizations I've worked with have gone so far as to establish a
 HelpDesk, manned by Systems people in rotation, just to deal with
 these types of issues. For some shops, it's worked out well; for others,
 it was a dismal failure. YMMV.
/snip/

In a past life, I was stuck on the help desk, and every programmer knew
where it was. Everytime they brought me a steaming hot dump fresh off
the printer and plopped it on my desk, I picked it up and handed it
back to them. I explained, I don't see any pencil marks on this dump
and no attempt by you to figure out what happened to YOUR program. Until
I see a serious effort on your part, don't expect me or any other help
desk person to assist you on debugging YOUR program. Then I point them
at the appropriate manuals, messages, codes, etc. and wish them the
best of luck.

A few complaints tried to work up the political food chain, but they
were always quashed when the salient points of the dispute were explained.
It's not the responsibility of help desk personnel to debug the programs
of the application programmers.

Glad those days are long gone...sigh.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: PARM= C compiler Options

2007-01-02 Thread Jeffrey D. Smith
Greetings,

The Systems/C compiler from http://www.dignus.com/ supports indirect
compiler options. In the PARM= or command line, you can point to a data set
name or dd name that has the options.

Check your compiler documentation to see if it has similar capabilities.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/


 -Original Message-
 On Fri, 13 May 2005 14:49:53 +0200, R.S. [EMAIL PROTECTED]
 wrote:
 
 BTW: I know *existing* OS/390 application using more than 256 bytes in
 PARM. It is c89 compiler. I vaguely recollect, it creates pseudo job
 for compilation, this job looks like regular JCL, but all the compiler
 options are in PARM field (many LINES of PARM) and that's why it is
 circumvented in some way. I don't remember details, but the need is
 obvious...
 
 I was given a whole C library full of functios to recompile. the number of
 parms on EXEC PGM=CCNDRVR exceed the PARM field length limit. Without
 editting indvidual functions what's the best work-around?
 
 Andreas F. Geissbuehler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: S0C1 with ILC 6

2006-12-20 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Shmuel Metz (Seymour J.)
 Sent: Tuesday, December 19, 2006 3:28 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: S0C1 with ILC 6
 
 In [EMAIL PROTECTED], on 12/18/2006
at 02:51 PM, Jeffrey D. Smith [EMAIL PROTECTED] said:
 
 As others have probably pointed out, the LA instruction does not
 generate the program interrupt. The instruction fetch causes it.
 
 I-Fetch is part of instruction processing.
 
 --
  Shmuel (Seymour J.) Metz, SysProg and JOAT

Having worked for several years on instruction emulation, I dare
say that I that can speak with authority on this subject. An
instruction is not processed until it is fetched. There is a clear
distinction between interrupts caused by attempted instruction
fetch (DAT errors, access exceptions, machine checks for double
bit errors on page frames, etc.) and the actual processing of the
fetched instruction.

There are some hints in the PoP about some models may initiate
instruction processing in parallel with fetching subsequent half-words
(i.e., after the first half-word is fetched and decoded). For example,
the Insert PSW Key (IPK) has 2 half-words, the second of which is always
ignored, but it must be accessible. Instruction processing for IPK can
begin as soon as the first half-word is fetched *and* decoded. If an
access exception occurs for the second half-word, then the
processing is backed-out. However, the IPK instruction did not
yield an access exception. The instruction fetch yielded the
access exception, which is distinct from (and sometimes in parallel
with) instruction processing.

In this particular instance of LA, I must completely disagree with
Shmuel's interpretation of instruction processing. Instruction
fetch is clearly distinct from instruction processing.

The LA instruction does not generate interrupts. All machine
instructions generate *only* those interrupts that are specifically
documented for the particular instruction in question. If the CPU
is unable to fetch the necessary half-words to determine what is
the next instruction, then instruction processing hasn't yet
occurred.

For some, this may seem like a distinction without a difference,
but it really is a significant difference to someone versed in
the architecture.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: S0C1 with ILC 6

2006-12-18 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Shmuel Metz (Seymour J.)
 Sent: Monday, December 18, 2006 11:16 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: S0C1 with ILC 6
 
 In [EMAIL PROTECTED], on 12/14/2006
at 03:08 PM, Chuck Arney [EMAIL PROTECTED] said:
 
 I think you are still confused.  :)  An LA instruction can not
 program check.
 
 It can if it straddles page boundaries and the second page is marked
 invalid. That's not something that you should see in an application
 program.
 
 --
  Shmuel (Seymour J.) Metz, SysProg and JOAT

As others have probably pointed out, the LA instruction does not
generate the program interrupt. The instruction fetch causes it.

This is similar to branching to an odd address causes a specification
exception on the *next* instruction fetch. The branch instruction
itself did not cause the interrupt PIC 0006; it was an early PSW
specification exception.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: S0C1 with ILC 6

2006-12-18 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of McKown, John
 Sent: Monday, December 18, 2006 12:17 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: S0C1 with ILC 6
 
/snip/
 
 Then what happens if the instruction starts at address x'00010FE' and
 address x'0002000' is either (1) fetch protected in a different key than
 the PSW key (assuming PSW key != 0) or (2) it has never been getmained
 and so is not a valid virtual address? That would have to be an S0C4 on
 instruction fetch. But wouldn't that have an ILC of 0?
 
 --
 John McKown

If the instruction fetch yields an access exception,
then ILC is random according to the PoP.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: What does a patent do that copyright does not?

2006-12-14 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Charles Mills
 Sent: Thursday, December 14, 2006 9:52 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: What does a patent do that copyright does not?
 
/snip/
 The invention is in the field of the prevention of software piracy. It is
 most suited for protecting consumer software, not commercial software.
 Much
 consumer software is protected with a key. You download the software,
 you
 try it, you pay for it, you get a key that enables it. But there is
 little
 to prevent you from sharing that key with your brother, your friends, or
 on
 a bulletin board.
 
 In my invention, the software requires the entry of two things to enable
 it:
 a key that is supplied by the vendor, AND the credit card number you used
 to
 buy the software. The key is constructed by the vendor from a hash of the
 product code and your credit card number. The purchased software re-
 computes
 the hash and compares it to the entered key.
 
 So you see, you *might* be willing to share the key AND your credit card
 number with your brother, but you're certainly not going to share your
 credit card number with random friends or on a bulletin board, and piracy
 is
 thereby discouraged.
 
/snip/

Seems very similar to public/private key cryptographic security. What stops
the consumer from cancelling the credit card account and getting a new
credit card account? Sharing a dead credit card account number on a forum
seems to circumvent the security invention? I guess it depends on how
expensive is the software and what the perceived benefit is for defeating
the security. OTOH, the dead credit card account number published on a
forum could be traced back to the original owner (I lost my wallet! yeah,
right!).

2 cents worth. Your mileage may vary.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IBM sues maker of Intel-based Mainframe clones

2006-12-14 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Warner Mach
 Sent: Thursday, December 14, 2006 6:43 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: IBM sues maker of Intel-based Mainframe clones
 
 Charles Mills wrote:
 
 I don't think so (but I'm not a patent attorney). If you can put your
 hand
 on a Bible and swear that you did not think you were infringing, then
 it's
 not willful infringement, AFAIK.
 
 I see where google has just released a search facility to search
 patents.
 This would, presumably, include software patents(?). Search seven
 million
 patents and be sure:
 
 http://www.google.com/patents

And I wish patent 5815096 never happened, for several reasons, including
those that I previously mentioned.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IBM sues maker of Intel-based Mainframe clones

2006-12-12 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Tom Moulder
 Sent: Tuesday, December 12, 2006 10:47 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: IBM sues maker of Intel-based Mainframe clones
 
/snip/
 
 Nor am I a lawyer, but it would appear to me that PSI lawyers could also
 attack the patent itself as being justified.  After all, how many ways can
 there be to round a number to the nearest integer?  Could you properly
 require every hardware manufacturer to come up with a new means for
 rounding?  And, why hasn't IBM gone after HP or SUN or anyone that uses a
 computer to round?  How about my TI calculator?  Does it round also?
 
 Tom Moulder

Please remember that the US Patent office also granted a patent for the
blinking cursor, because it utilized an innovative non-obvious application
of the mathematical exclusive-OR concept.

I patented a data compression process, and I saw how the sausage was made
at the patent office. For many reasons, I think patenting software is a
very bad idea. I think copyright protections are stronger and easier to
enforce. Software patents are mostly for Public Relations and marketing.

Anyone adequately educated in the art of software development could invent
most of the patented software processes. A developer's only limiting reason
is motivation. Necessity is the mother of invention. Unfortunately, most of
the patent reviewers are not well-versed in commercial software development.
What seems innovation and non-obvious to them is quite the opposite to real
software developers that write code for a living.

Just-In-Time (JIT) code translation is everywhere and it has been around
for a long time. Translating copyrighted software from one executable form
into another (transient) executable form without exposing the target form to
the outside world doesn't dilute the value of that software, IMHO. I think
there is viable adversarial battle, and shining a bright light on both
parties can only help the mainframe market.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IBM sues maker of Intel-based Mainframe clones

2006-12-12 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Howard Brazee
 Sent: Tuesday, December 12, 2006 2:30 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: IBM sues maker of Intel-based Mainframe clones
 
 On 12 Dec 2006 12:40:27 -0800, [EMAIL PROTECTED] (Jeffrey D.
 Smith) wrote:
 
 I patented a data compression process, and I saw how the sausage was made
 at the patent office. For many reasons, I think patenting software is a
 very bad idea. I think copyright protections are stronger and easier to
 enforce. Software patents are mostly for Public Relations and marketing.
 
 Do you think it is a bad idea for companies to patent their software?
 As opposed to, say, trade secrets?
 
 Arguments for this are of interest to software developers.
 
 Or do you think the concept of patents which has been very good in the
 past needs re-thinking.I can see quite a few arguments that its
 useful cycle is nearing its end.   (We can't patent recipes, but
 there's a thriving recipe business)   (Many times patents are used not
 to innovate these days, but to stop competition)
 
 This discussion is of great interest to all - but not so much in this
 forum.
/snip/

Software patents are processed by the same folks who review electronic
circuitry patents. If a process is distilled down to an electronic
circuit device, then that is a physical *implementation* which I think,
IMHO, should be eligible for patent consideration.

OTOH, software is a written list of directions to be obeyed by a
hardware device in the course of receiving input data, processing
that data, then producing output data. If the directions are changed,
then the output is changed, but the hardware remains unchanged.

This is the fundamental difference between hardware and software
implementations of data processing algorithms. I think the difference
is so significant that software patents should not exist. Software
should be protected by copyright.

Trade secrets are exactly what the name says. It's a secret, so it's
not published anywhere. Patents, OTOH, are by definition published to
provide constructive notice to the world. A patent applies to a
implementation of a *process*, not to an idea. I believe that software
is a written representation of an idea and not a process. It is the
computer device that actually performs the process as directed by the
software. I think extending the concept of implementation beyond
physical hardware to the software was a mistake.

I can understand and accept the notion of patenting a new physical
device for making doughnuts. I won't accept the notion of patenting
the doughnut recipe(s) that is used by the new device. The recipe may
be copyrighted, but not patented IMHO. The recipe is the set of
directions (like software) for making doughnuts with that particular
doughnut-making device. Translating the recipe to operate with a
different doughtnut-making device may violate the copyright, but it
certainly doesn't make sense to claim patent infringement.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IBM sues maker of Intel-based Mainframe clones

2006-12-11 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of John P Baker
 Sent: Monday, December 11, 2006 3:21 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: IBM sues maker of Intel-based Mainframe clones
 
 If I understand the filing, I believe that the difference is that both
 FLEX-ES and Hercules are in fact instruction simulators, whereas PSI was
 producing an instruction emulator.
 
 IBM alleges that what PSI is doing is translating executable object code
 for
 zSeries into executable object code for Itanium.  That translation is what
 is in violation of IBM's patents and licensing agreements.
 
 The differences between the two are obscure to non-technical types, but
 should be easily understandable to anyone having a background in hardware
 architecture.
 
 In the case of the developers of both FLEX-ES and Hercules, I think that I
 would be sure to say that what I have is an instruction simulator.
 
 John P Baker
/snip/

Both FLEX-ES and Hercules are emulators to the extent that a s/390 or
z/Architecture program using only the machine instructions that are
documented in the PoP cannot determine that it is not running on
a native IBM box. By the way, both emulators also support several machine
instructions that are not publicly documented by IBM. z/OS relies on
some of those undocumented instructions.

The only argument that IBM can have with any emulator provider is
when the provider supports undocumented instructions. IBM got slapped
with a consent decree several years ago, requiring IBM to disclose
such undocumented instructions to its competitors. It was called a
TIDA (Technical Information Disclosure Agreement) document, and it
was expensive. A TIDA document looks and reads just like the PoPs
description of a single machine instruction.

Now that IBM doesn't have to disclose such information to plug-compatible
competitors, any competitor that can successfully run z/OS must be using
undocumented machine instructions. z/OS cannot run on a machine that only
supports the z/PoPs machine instructions. In order to run z/OS, the
competitor must use a real IBM box and try to reverse engineer the
undocumented instructions. This was common practice in the old consent
decree days for Amdahl and Hitachi, because for some instructions it
was cheaper than paying for a TIDA document.

I think the patent lawsuit will likely boil down to a you may not reverse
engineer IBM z/Architecture complaint. It seems that PSI's only defense
is to re-argue the old consent decree case, in effect, that IBM is a
monopoly when it controls the hardware and the operating system.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IBM sues maker of Intel-based Mainframe clones

2006-12-05 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Nigel Hadfield
 Sent: Tuesday, December 05, 2006 11:57 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: IBM sues maker of Intel-based Mainframe clones
 
 It's difficult to see why they are suing, especially when they never sued
 PCMs in previous generations. Surely they could simply refuse to licence
 z/OS on the PSI machines. That would put PSI out of business just as
 quickly.
 
 Nigel

Maybe z/Linux would be a viable alternative?

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Z9 CPU too fast :-)

2006-11-30 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Chase, John
 Sent: Thursday, November 30, 2006 12:35 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Z9 CPU too fast :-)
 
 On the lighter side
 
 Been getting some change control approval requests from the folks who
 maintain a rather ancient CICS/VSAM application here.  In Reason for
 change they put New CPU too fast.
 
 Seems that since we implemented the new z9 processors, parts of the
 application that generate VSAM record keys that include date and time
 have been generating duplicate keys.  :-)
 
 -jc-

I would venture a guess that the real problem is an application
design or implementation error. The faster CPU speed has simply
exposed the flaw in the application that was already there, yet
undetected until now. New CPU too fast is not the cause, only
the necessary and sufficient condition to expose the symptom.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Descriptive term for reentrant program that nonetheless is not multi-taskable?

2006-11-28 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Arthur T.
 Sent: Tuesday, November 28, 2006 8:47 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Descriptive term for reentrant program that nonetheless is
 not multi-taskable?
 
 On 28 Nov 2006 05:51:27 -0800, in bit.listserv.ibm-main
 (Message-ID:[EMAIL PROTECTED])
 [EMAIL PROTECTED] (Tom Marchant) wrote:
 
 I'd say, it is simply *not* reentrant and has the RENT
 bit set
 incorrectly. Anyone can set the RENT bit on his module,
 but that does
 not mean it is coded reentrant, which apparently is also
 true for this
 code.
 
 Kees.
 
 You're right, Kees. The module is reenterable. It can be
 executed by more than one task at a time.
 
   But, as described, the module may be LPA-eligible and
 usable by multiple address spaces at the same time.  It
 just isn't useful to attempt using it by multiple tasks
 within one address space at the same time.  So, it is more
 than serially reusable, and the RENT bit does give useful
 information.
 
   I was waiting for someone else to say it, but here's
 adjectives I'd use to describe such code: badly-written
 or badly-designed.  Or, am I missing a good reason
 (unrelated to the hard-coded DDNAMEs) that FTP shouldn't be
 used by multiple tasks within one address space?
 

Why not just say it is a reentrant job step program? That describes
that it is reentrant (LPA-eligible for use by multiple jobs) and it
must be a job step program (a job executes only one step at a time)
so it has exclusive access to the DD names for the step.

Trying to run a job step program as something other than that
will cause problems. Is it the responsibility of the program to
ensure that it only runs as a job step program?

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: News : IBM and outsourcing in Texas

2006-11-26 Thread Jeffrey D. Smith
There's no Texas state personal income tax. There are plenty of other kinds
of state taxes, and I am certain the citizens want their public monies
managed properly.

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Ed Finnell
 Sent: Sunday, November 26, 2006 1:18 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: News : IBM and outsourcing in Texas
 
 
 In a message dated 11/26/2006 11:51:12 A.M. Central Standard Time,
 [EMAIL PROTECTED] writes:
 
 This is  not about SAving your Tax Dollars and there is no State Tax in
 Texas.
 It's not about saving dollars at  all.
 
 
 
 
 
 You can prove just about anything by quoting out of context.
 
 There's no State Income tax, but the revenue has to come from somewhere to
 provide services:
 
 _http://www.window.state.tx.us/taxbud/revenue.html_
 (http://www.window.state.tx.us/taxbud/revenue.html)
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Any issues with application programs write protecting themselves?

2006-11-22 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of (IBM Mainframe Discussion List)
 Sent: Wednesday, November 22, 2006 6:57 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Any issues with application programs write protecting
 themselves?
 
 It is not necessary to UNPROTECT storage before freeing  it.
 Jim Mulder   z/OS System Test   IBM Corp.   Poughkeepsie,  NY
 In z/OS V1R6.0 MVS System Codes doc the following ABENDs are  documented
 for
 FREEMAINs involving protected storage:
 605-08, 605-10, 605-18, and B78-10.
 
 Bill  Fairchild
None of those apply to FREEMAIN of write-protected storage (PGSER PROTECT).

ISTR the abend occuring in pre-OS/390 days, but my recall is hazy. It could
be that I am confusing store-protected with page-fixed. FREEMAIN of
page-fixed I believe is still a no-no. Anyway, my coding style is to undo
whatever I did before my program ends. If I page-fix it, then I release it.
If I allocate it, I unallocate it. If I write-protect it, then I make it
read-write.

I am generally averse to acquiring a resource, then relying on the operating
system to release it.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Any issues with application programs write protecting themselves?

2006-11-21 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Jim Mulder
 Sent: Tuesday, November 21, 2006 6:53 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Any issues with application programs write protecting
 themselves?
 
 IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/21/2006
 06:30:15 PM:
 
   Will CSV have problems when the module is explicitly DELETE'd, or
 during
   cleanup at step termination time?
 
  You must UNPROTECT before attempting to delete the module. Else you'll
 get
  a FREEMAIN abend.
 
   It is not necessary to UNPROTECT storage before freeing it.
 
 Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

When did that change? I distinctly remember FREEMAIN abends for
read-only storage.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: assembler question (strong typing)

2006-11-19 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Paul Gilmartin
 Sent: Saturday, November 18, 2006 8:35 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: assembler question (strong typing)
 
/snip/
 I pretty much agree, though I'm somewhat uncomfortable with further
 overloading USING.  It's bursting at the seams with labelled and
 dependent USINGs.  And how would this work with the new-fangled
 baseless code, particularly in the case discussed recently where
 code from two different sources is merged with an editor or with
 COPY?

/snip/

 -- gil

I had a subroutine with ranged USING to prevent based references
beyond the bounds of the subroutine.

I converted the subroutine from based branch to relative branch. Then I
copy-pasted the subroutine to another location in the same CSECT, and
manually changed the branch target labels. The new subroutine also had a
ranged USING. Everything assembled RC=0.

Upon perusal of the assembly listing, I noticed that some of the
relative branches in the new subroutine were referring to labels in
the old subroutine outside of the ranged USING. The relative branches
were ignored by the ranged USING, because there were no base
registers to test in the relative branch instructions.

Rather than try to dig around in the assembler documentation to find
a way to generate a warning/error message for this situation, I just
converted the routines back to RX-type branches. Problem solved.

I doubt there is any significantly measurable difference in the
performance between RX-type and relative branch instructions.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: assembler question (strong typing)

2006-11-19 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Charles Mills
 Sent: Sunday, November 19, 2006 2:39 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: assembler question (strong typing)
 
 Gee, in my impression, and in my expectations, a USING range check is just
 that: a check to make sure that the displacement in within the limits
 specified.
 
 I would not expect it to have any effect on relative jumps.
 
 Yes, local-scope labels would be a wonderful thing, but that's a *big*
 enhancement, and in any event, not what the displacement range check does
 (although it could be used in limited circumstances to provide a limited
 amount of locality checking).
 
 I use the range check for an uh-oh, you're in danger of running out of
 your
 4096 bytes of addressability check. Does anyone know of another
 intended
 use?
 
 Charles
/snip/

My ranged USING is for position-independent subroutines that I copy into
common storage. I don't want my subroutine code looking past its own
boundary into foreign storage.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: assembler question (strong typing)

2006-11-18 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of john gilmore
 Sent: Saturday, November 18, 2006 8:10 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: assembler question (strong typing)
 
 Clark Morris writes of the HLASM:
 
 
 It may be low level, but does it also have to be brain-dead?
 
 
 Characterizing the HLASM as brain-dead because it does not do strong
 typing
 gives polemical expression to one point view.  Other, different views are
 possible; they are indeed entertained by experienced people.
 
 I, for one, loathe strong typing.  In my own code I do data-type punning
 routinely, and I should not wish to see the HLASM converted into as C-
 lilke
 language that made this gratuitously difficult.
 
 The whole question whether the HLASM or any assembly language is now a
 suitable vehicle for use by novices is, I think, an open one.  Let them
 write C or Pascal!  Devoting any of the very limited resources available
 for
 maintaining and enhancing the HLASM to childproofing it would come far
 down
 on my personal wish list for it.
 
 John Gilmore

Greetings,

Systems/C by www.dignus.com generates HLASM output, which is subsequently
processed with an HLASM-compatible assembler. At any point, the C source
code can drop down to assembler using the __asm {} block. There are other
features for controlling register usage, using 64-bit addresses and
ALET-qualified pointers, reentrant and non-reentrant. Systems/C programs can
be designed to run in task mode, SRB mode, cross memory code.

Such a compiler is a very educational tool for showing C programmers how
the C language idioms are translated directly into assembler source code.

The shortage of good assembler programmers can be mitigated by hiring good
C programmers and using Systems/C as a development and educational tool. As
the C programmers become educated in mainframe assembler by looking at the
generated assembler, they can write assembler-only subroutines and easily
call those routines directly from their Systems/C programs. It's a great way
to ease into mainframe assembler programming from a higher level language.

Also, a good set of debugging tools is vital for understanding the
difference between what you thought you wrote compared to what you
actually wrote. Go to www.colesoft.com for state of the art debugging
tools.

2 cents worth. Your mileage may vary.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: assembler question (strong typing)

2006-11-18 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Paul Gilmartin
 Sent: Saturday, November 18, 2006 8:00 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: assembler question (strong typing)
 
 In a recent note, Charles Mills said:
 
  Date: Sat, 18 Nov 2006 17:39:22 -0800
 
  You could do some of that with labeled USINGs.
 
 But only some.  It requires the programmer to explicitly qualify
 each symbol use
 
 I recall vaguely that the 709 (et. al.) assembler, FAP, had
 an operation called HED that did something like that.
 
  -Original Message-
  From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf
  Of Gerhard Postpischil
  Sent: Saturday, November 18, 2006 5:35 PM
 
  If John E. is lurking, there is one feature I'd really love to
  see - qualifiers. Suppose you wish to combine two programs that
  have duplicate variables - prefix each code section with a
  qualifying name, and the assembler correctly resolves the local
  references. In a way this was a precursor to the way unexposed
 
 -- gil
/snip/

The flat namespace of HLASM is the real problem. There should be
a way to hide labels within a DSECT until the DSECT is anchored
with a USING. Until the owning DSECT is made addressable through
a USING, the symbol should not conflict with the same name of a
symbol defined in another DSECT. If more than one symbol of the
same name (in different addressable DSECTs), then issue an error
message. Otherwise, just use the symbol that is addressable. There
should be some syntactical sugar that indicates the programmer
knows there are multiple symbol matches and knows the consequences
of using the wrong symbol.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Assembler question

2006-11-07 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Steve Comstock
 Sent: Tuesday, November 07, 2006 6:38 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Assembler question
 
/snip/
  Best practice:  MVC TARGET(6),=XL6'402021212121'
 
 So why does the Assembler even bother calculating
 length values? I disagree on two points:
 
* Never use literals; always define a constant
  and reference the label on the constant
 
* Never code explicit lengths unless you are
  not using the value generated by the Assembler
 
 But I realize these are points of style / preference /
 local standards. I do not intend to start a holy war,
 these are just my preferences.
 
  Note the length modifer.  This surfaces both the exact length of the
  source and the exact length of the move.  People who omit the length
  modifer are sentenced to the 9th level of hell for all eternity.  Or
 even
  longer.
 
 Well, there ya' go, the holy war has begun. But let's not
 persist. We let our opinions be known and now we move on.
 
 Kind regards,
 
 -Steve Comstock
/snip/

For my 2 cents worth:

1. I would like a controllable warning when the MVC/CLC target is
*longer* than the source literal operand. If the source operand
is not a literal, then trust the programmer and be quiet.

2. HLASM seems to treat MVC FOO(1),BAR the same as MVC FOO(0),BAR.
I cannot think of a clean way to flag an improper FOO(0) while not
flagging a proper FOO(0). The MVC may be the target of EX. Perhaps
something like qualifying the MVC mnemonic?

MVCFOO(0),BAR   this gets flagged
MVC.EX FOO(0),BAR   this is an EX target and not flagged

It's not backward compatible and it's awkward. Suggestions for
improvement are welcome.

3.  I prefer using labeled constants with implied lengths instead of
literals. I use an ASSERT macro to ensure compatible source/target
lengths. An HLASM implied check would be more convenient.

4.  Compiler-generated source code can be very weird, but legitimate.
Any new warnings/errors/flagging should be controllable/suppressable.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: COND CODE 3592

2006-11-06 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Tony Harminc
 Sent: Monday, November 06, 2006 11:16 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: COND CODE 3592
 
 Phil Payne wrote:
 
   Maybe the program was converted from VSE which, in the days
  when it was DOS anyhow, used an SVC macro to end the job.
 
  So, effectively, does z/OS.  ISTR that R14 in a jobstep  programme
 points
 directly
  at an SVC 3 instruction.
 
 It points at CVTEXIT, which contains a handy SVC 3. Unless you are running
 under TSO TEST, in which case it points to an SVC 97, which has fooled
 more
 than one program that tries to decide if its task is about to end.
 
  You used to be able to tell if you were the jobstep programme by looking
 at that.
 
 That I doubt; all programs initially getting control from the operating
 system have R14 pointing at CVTEXIT.
 
 Tony H.

ISTR that an SRB program has R14 pointing elsewhere.

/J

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Assembler question

2006-11-06 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Patrick O'Keefe
 Sent: Monday, November 06, 2006 2:01 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Assembler question
 
 On Mon, 6 Nov 2006 13:37:50 +0100, Chris Mason [EMAIL PROTECTED]
 wrote:
 
 ...
 I was commenting on the following instruction:
 
   MVC   M1CC-1(L'M1CC+1),=X'402120202020' MOVE IN EDIT MASK
 ...
 The task is to move a 6-character string into a storage area. There needs
 to
 be some symbolic reference to the storage area so the M1CC variable is
 used.
 ...
 
 I'm afraid I don't understand what the issue is.  Seems to be a matter of
 style.  I see the task as moving a edit mask into a field that starts one
 byte prior to M1CC and extends to the end of M1CC.  I have to build the
 mask so have to know that the length is 6 but M1CC-1(L'M1CC+1)explains
 why it is 6.  Is that bad?
 
 Actually, if I had to do that more than once or twice I'd probably write
 a macro that builds both the MVC and the mask, and would (hopefully)
 comment it well enough that a neophyte would understand.
 
 Pat O'Keefe

The main issue for me is that the literal has a hard-coded length,
while the other operand uses a symbolic reference for the length. If
the symbol changes, there is no warning that the literal is now the
wrong length.

In situations like this, I usually add an assertion that insists on
equality between the symbol and the literal length, but that is still
vulnerable to maintenance errors.

A  EQU L'M1CC+1
B  EQU 6

   MVC   M1CC-1(A),=XL(B)'402120202020' MOVE IN EDIT MASK
   DS  ((A-B)*(B-A))X

If A is unequal to B, this causes an assembly-time error. I use an
ASSERT macro to hide the DC details, which makes the source code
easier to read.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: The PSI Letter V4

2006-11-03 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Steve Comstock
 Sent: Friday, November 03, 2006 6:57 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: FW: The PSI Letter V4
 
 Knutson, Sam wrote:
  More news from PSI on the state of their commercial emulation solution.
  The next few months seem to hold the potential for interesting
  developments in this area.
 
  Thanks, Sam
 
 
 Interesting. Can you do a rough comparison of
 PSI's offering to FLEX-ES and Hercules? Can
 PWD people get the software at low cost for
 all three platforms (well, I know right now
 that Hercules cannot legally run z/OS without
 some special dispensation).
 
 Clever term open mainframe, but what does it
 really mean? Certainly not open in the open
 source sense?
 
 Kind regards,
 
 -Steve Comstock

What I don't understand is if IBM won't allow z/OS to run on
a Hercules system, then why would IBM allow z/OS to run on
a PSI system?

/J

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Why would Rexx Date/Time be different from ASCBEWST Date/Time?

2006-10-28 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Thomas Berg
 Sent: Saturday, October 28, 2006 11:17 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Why would Rexx Date/Time be different from ASCBEWST
 Date/Time?
 
 ==  Paul Gilmartin  ==  wrote2006-10-25 17:43:
  In a recent note, Lindy Mayfield said:
 
  Date: Wed, 25 Oct 2006 16:47:00 +0200
 
  date=DATE(U)
  time=TIME()
  ...
  Say 'Rexx Date/Time:' date time
 
  Do not do this.  There's a (small) chance that the date will change
  between the two calls, and the result printed will be in error
  by 24 hours; a nasty bug for being almost impossible to reproduce.
  Rather, do:
 
Say 'Rexx Date/Time:' DATE(U) TIME()
 
  I recognize this is a one-off, but as mentioned recently in these
  lists, one-time code has a nasty habit of creeping into production,
  as do careless habits practiced in one-time code.
 
  -- gil
 
 There is still a small(er) chance that the date changes between the
 resolution of the Date() function and the resolution of the Time()
 function.  (AFAIK)
 Haven't found a really clean solution to this problem.  Anyone ?
 
 Thomas Berg

Could you get the date before and after getting the time. Then
check the two dates for a match? If mismatch, then loop back and
try again.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?

2006-10-25 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Shmuel Metz (Seymour J.)
 Sent: Wednesday, October 25, 2006 7:22 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
 defensible?
 
 In [EMAIL PROTECTED], on 10/22/2006
at 08:31 PM, Jeffrey D. Smith [EMAIL PROTECTED] said:
 
 No, that's reentrant.
 
 RYFM.
 
 Refreshable means the program does not
 modify itself *ever*.
 
 No. It means that the program produces correct results even if
 refreshed. It can modify itself as long as losing the modifications
 doesn't cause incorrect results.
 
 A program is reentrant if it produces correct results when multiple
 invocations run concurrently. A R/O program can fail to be reentrant,
 and a reentrant program can modify itself. It can even modify itself
 without serialization if it does not subsequently rely on the results
 of the modification.
 
 No, reentrant means what I wrote.
 
 RYFM.
 
 Serialization has nothing
 to do with it, unless the program is self-modifying (which is also
 what I wrote).
 
 That's what you wrote, but it's wrong.
 
  L R0,CVTUSER
  BCTR  R0,0
  STR0,CVTUSER
 
 Refreshable, in fact R/O, but not reentrant; it needs serialization.
 
 It's not what you don't know that's the killer; it's what you know
 that isn't so.
 
 --
  Shmuel (Seymour J.) Metz, SysProg and JOAT

IBM Documentation, Program Management SC27-1130-00
Chapter 7, Binder Options, Page 123.

The syntax of the REUS option is as follows: 
REUS={NONE|SERIAL|RENT|REFR} 
The reusability values are: 

NONE 
The module cannot be reused. A new copy must be brought into virtual 
storage for each use. NONE is the default value.
 
SERIAL The module is serially reusable. It can only be executed by one task
at a time; when one task has finished executing it another task can begin. A
serially reusable module can modify its own code, but when it is reexecuted
it must initialize itself or restore any instructions or data that have been
altered. 

RENT The module is reenterable. It can be executed by more than one task at
a time. A task can begin executing it before a previous task has completed
exe-cution. A reenterable module cannot modify its own code. In some cases,
the operating system may load a reentrant program into an area of virtual
storage that cannot be modified. 
Reenterable modules are also serially reusable. 

REFR The module is refreshable. It can be replaced by a new copy during
execution without changing the sequence or results of processing. A
refreshable module cannot be modified during execution. 

A module can only be refreshable if all the control sections within it are
refreshable. The refreshable attribute is negated if any input modules are
not refreshable. Refreshable modules are also reenterable and serially
reusable. 
The refreshable attribute can be specified for any nonmodifiable module.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?

2006-10-23 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Knutson, Sam
 Sent: Monday, October 23, 2006 9:37 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
 defensible?
 
 Hi Gilbert,
 
 If you want to round out the modules to allow you to page protect them
 perhaps something like this instead of the special link edit procedure.
 
 *
  LTORG ,
 *
 *  round this module to a page boundary for page protect
  DC((*+4095-DRIVER)/4096*4096-(*-DRIVER))X'00'
 DRIVERL EQU   *-DRIVER
 
 Best Regards,
 
 Sam Knutson, GEICO
/snip/

I use a very simple-minded approach in most of my programs.

COMBAR  COM   ,
FOOBAR  CSECT ,
FOOBAR  AMODE 31
FOOBAR  RMODE ANY
* Put entry logic here.
* Put everything else here.
* Maybe add some padding here.
ENDBAR  END   ,

In the link-edit step, I mark FOOBAR and COMBAR as page-aligned.
The linkage editor always puts COM sections at the end by
default. The COM section is zero bytes, so it's placed at a
page boundary at the end of the module. The module is now
page-aligned and page-multiple size. I also mark (REFR,RENT),
although I *think* the binder will automatically mark RENT
when it sees REFR. (Refreshable implies reentrant.)

I will sometimes use a DC statement before the END to force
page alignment, but it gets complicated when I have multiple
LOCTR names in effect. I must remember to resume the CSECT,
then generate a new LOCTR name, then add the DC statement.

The linkage-editor approach with the COM section is simpler
and it works.

2 cents worth. Your mileage may vary.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: BCTR out of favor?

2006-10-23 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Charles Mills
 Sent: Monday, October 23, 2006 10:17 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: BCTR out of favor?
 
 While we're on the subject of machine performance .
 
 Do I recall correctly hearing that BCTR Rn,0 is no longer the favored way
 of
 decrementing a register, perhaps because the cache logic sees it as a
 potential branch, and that AHI Rn,-1 should be substituted?
 
 Similarly, that AHI is preferable to LA for adding a small increment to a
 register, perhaps because LA may invoke or reserve the address
 translation
 logic?
 
 Charles Mills

BCTR Rn,0 is alright for unsigned decrement. The branch target register
is recognized as zero (never branch).

I recommend always using LA when dealing with addresses. I prefer to use
LA for small integer arithmetic.

I don't use AHI much, but it has its place.

Whatever you decide, be consistent and keep it simple for the next
maintenance programmer.

2 cents worth. Your mileage may vary.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?

2006-10-23 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Paul Gilmartin
 Sent: Monday, October 23, 2006 11:13 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
 defensible?
 
 In a recent note, Bruce Black said:
 
  Date: Mon, 23 Oct 2006 12:42:18 -0400
 
  Also, the ORDER statement (which orders csects) has a P option to align
  a specific csect on a page boundary.  You can also use it to specify the
  load module that follows it to fill in the rest of the page.
 
 load module or CSECT?
 
 It's frustrating that ORDER provides no construct to place a
 specified CSECT _last_.
 
 Here might be a legitimate use for an empty CSECT/load module/
 program object.  But, as I note frequently, IBM does a miserable
 job of supporting this boundary condition.
 
 -- gil

As I wrote in another post, I use an empty COM section, because the
binder always puts common sections at the end (by default).

The assembler looks like this:

COMBAR COM ,
FUBAR  CSECT ,
FUBAR  AMODE 31
FUBAR  RMODE ANY
* Put entry logic here.
* Put more CSECTS and data here.
ENDBAR END ,

Just use something like:
//SYSLIN DD *
 ENTRY FUBAR
   ORDER FUBAR(P)
   PAGE  COMBAR
   NAME  FUBAR
/*

The CSECT FUBAR is page-aligned first. The empty common section
COMBAR is page-aligned last. Any other CSECTs in the module are
placed between FUBAR and COMBAR. Problem solved.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?

2006-10-22 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Paul Gilmartin
 Sent: Sunday, October 22, 2006 9:20 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
 defensible?
 
/snip/
 Does EX count as an I-fetch or a D-fetch?  (Could even be model-
 dependent)
 
 -- gil
/snip/

The target instruction for EX is an I-fetch, because it can
trigger a PER program interrupt.

OTOH, the in-line parameter list for Resume Program (RP)
is a D-fetch in the I-space. Weird.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?

2006-10-22 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Edward Jaffe
 Sent: Sunday, October 22, 2006 8:38 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
 defensible?
 
 Paul Gilmartin wrote:
  On Sat, 21 Oct 2006 15:44:00 -0600, Jeffrey D. Smith
 [EMAIL PROTECTED] wrote:
 
/snip/
  The only way to know for sure is to put the program into
  read-only storage. An unauthorized program can do that by
  using the IARVSERV or PGSER to page protect the program
  after it is loaded. The program must be marked page-aligned
  and the size must be an exact multiple of a page.
 
 
  There has also been discussed on ASSEMBLER-LIST a secret PARMLIB
  option that when set causes all code, authorized or not, marked
  RENT to be loaded in a write-protected subpool.  There was a URL
  for an IBM presentation.
 
 
 Write-protected subpools?! No such thing!
 
 I mentioned the CsvRentSp252 DIAG trap earlier in this thread.. What
 that does is put RENT code into subpool 252, which is key zero storage.
 Therefore, programs running in PSW key zero can modify SP 252 storage.
 
 To get complete protection of all RENT modules, you must use the
 CsvRentProtect DIAG trap. That uses PGSER PROTECT to protect the modules
 once they're loaded. I don't recommend that setting on systems older
 than z/OS V1R8 because there are several popular IBM programs, residing
 in SP 252, that legitimately update themselves and whose module names
 don't appear in the exception table until that release.
 
 [Disclaimer: DIAG traps are not intended for use on production systems.]
 
 --
 Edward E Jaffe
/snip/

I prefer rolling my own IARVSERV or PGSER cover program, because it
only affects my job step address space and not the entire system. I guess
on a single-user system, like a FLEX-ES (rest in peace), the DIAG stuff
would be OK.

It doesn't take much work to LOAD the target program, figure out the
boundaries and issue PGSER PROTECT (or IARVSERV ACCESS=READONLY). Then
on the way out, be sure to unprotect the pages before issuing DELETE.

Protected pages are not foolproof, but certainly stronger than relying
on key 0 storage to detect self-modifying reentrant programs.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?

2006-10-22 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Shmuel Metz (Seymour J.)
 Sent: Sunday, October 22, 2006 12:06 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
 defensible?
 
 In [EMAIL PROTECTED], on 10/21/2006
at 10:19 AM, Jeffrey D. Smith [EMAIL PROTECTED] said:
 
 Mainframers tend to use the word reentrant to mean
 a program that is concurrently executable by multiple
 units of work and it does not modify itself at all (or
 may modify itself in a way that is not detectable by
 the multiple units of work that are concurrently executing the
 program).
 
 That's refreshable.

No, that's reentrant. Refreshable means the program does not
modify itself *ever*. A reentrant program may modify itself
in a way that is not detectable by concurrently executing
units of work. That's what I wrote.

 Reentrant means that you get correct results when
 running concurrent copies, which typically requires some sort of
 serialization.

No, reentrant means what I wrote. Serialization has nothing
to do with it, unless the program is self-modifying (which is
also what I wrote).

 --
  Shmuel (Seymour J.) Metz, SysProg and JOAT
/snip/

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?

2006-10-21 Thread Jeffrey D. Smith
Non-mainframers tend to use the word reentrant to mean
what we mainframers would call recursive.

Mainframers tend to use the word reentrant to mean
a program that is concurrently executable by multiple
units of work and it does not modify itself at all (or
may modify itself in a way that is not detectable by
the multiple units of work that are concurrently executing
the program).

btw: I would offer the definition of non-reentrant to be a
program designed either to modify itself or a program that
may misbehave when executed concurrently by multiple units
of work.

Mainframers tend to use the word refreshable to mean a
program that does not modify itself at all, so that it could
be refreshed from external storage medium at any time *and*
any concurrently executing units of work would not detect
the refresh. A refreshable program is also specifically
designed for correct behavior during concurrent execution
by multiple units of work.

btw: I always write my reentrant programs as though they
are refreshable. I always design my programs to be
reentrant *unless* there is a specific reason that requires
the program to be non-reentrant. Personal convenience alone
is not sufficient justification to design a program as
non-reentrant, other than for a throw away program that
I expect to use only once.

2 cents worth. Your mileage may vary.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Rick Fochtman
 Sent: Saturday, October 21, 2006 9:53 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
 defensible?
 
 snip
 A program that is re-entrant according to the strict definition is one
 that spontaneously re-enters itself. We call such behavior a loop.
 -unsnip---
 Sometimes we call it recursion. G
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?

2006-10-21 Thread Jeffrey D. Smith
A reentrant program need not use GETMAIN/FREEMAIN/STORAGE. I've written
zillions of reentrant routines that rely on the caller to provide a
work area or that rely on pre-allocated storage areas (usually PC routines).

Using pre-allocated or caller-specified work areas is extremely fast. If
a caller provides a work area that is allocated within itself, then the
caller is non-reentrant, but the called routine is still reentrant.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of John P Baker
 Sent: Saturday, October 21, 2006 10:17 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
 defensible?
 
 If the reentrant program must acquire and release storage (via
 GETMAIN/FREMAIN or STORAGE ACQUIRE/RELEASE) during each invocation, I can
 not see how the operation of the internal cache is going to make a
 difference of sufficient significance to support the performance
 assertion.
 
 If the reentrant program does not have to invoke these or other system
 services, it may be a different matter.  In fact, I would expect the
 performance characteristics to be quite different.
 
 My experience is that the assertion that reentrant programs ALWAYS perform
 better than non-reentrant programs can not be justified.  There are simply
 too many variables involved.
 
 John P Baker
/snip/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?

2006-10-21 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Robert A. Rosenberg
 Sent: Saturday, October 21, 2006 3:09 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
 defensible?
 
 At 07:58 -0700 on 10/21/2006, Charles Mills wrote about Re: Is the
 teaching of non-reentrant HLASM coding practices:
 
 And then there is no way to test that the code really is reentrant (that
 I
 know of -- am I missing something?) without running it APF-authorized.
 
 Use RENT as well as RSECT instead of CSECT and you will get TOLD at
 assembly time when you're not reentrant.

Not every time.

LA  R3,FUBAR
ST  R2,0(0,R3)

No way for the assembler to determine that the ST is storing
into field FUBAR.


The only way to know for sure is to put the program into
read-only storage. An unauthorized program can do that by
using the IARVSERV or PGSER to page protect the program
after it is loaded. The program must be marked page-aligned
and the size must be an exact multiple of a page.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW:A Letter To The FLEX-ES Community

2006-10-06 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Jon Brock
 Sent: Friday, October 06, 2006 12:10 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: FW:A Letter To The FLEX-ES Community
 
 Gaudere's Law (aka Merphy's Law) strikes again.  Or maybe agin.
 
 Jon
 
 
 snip
 When you correct someone else's spelling, mistakes make you look really
 foolish. I surmise you meant you're going ?
 /snip

And MURPHY'S LAW strikes YET again.

It's a weak mind that can think of only one way to spell a werd.

/J

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Wars and Allies (was: The Fate of VM)

2006-09-22 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Thompson, Steve (SCI TW)
 Sent: Friday, September 22, 2006 12:31 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Wars and Allies (was: The Fate of VM)
 
 
 Perhaps this saying might put things into proper perspective:
 
 Those of you who think you know it all really annoy the _ out of us
 who do.
 
 Regards,
 Steve Thompson

Religion has probably caused more wars and suffering than communism
or any other non-religious cause. It's an argument over who has the
better imaginary friend. It's been going on seen divinity was invented
to answer the question (and calm our fears) about death, and later it
was subverted for social control. 

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: The ASCRE initialization routine

2006-09-20 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Jim Mulder
 Sent: Wednesday, September 20, 2006 3:40 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: The ASCRE initialization routine
 
 IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/20/2006
 11:21:40 AM:
 
/snip/
   Since the region subpools are not freed, any region subpools used
 during the initialization routine will continue to be key 0, when they
 would usually be key 8 or the PPT key.  So, for example, if you LOAD
 a non-reentrant module during the initialization routine, subpool 251
 will be created as a key 0 subpool.  Then later when your jobstep task
 gets attached, since the region was not freed, subpool 251 will still
 exist as a key 0 subpool.  Subsequent LOADs of non-reentrant modules
 into subpool 251 will be into key 0 storage (and fetch protected),
 so you won't be able to execute them unless you are running key 0.
 Also, the REGION/IEFUSI limits will not be honored.
 
 Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

I would have guessed that attaching the job step task (EXEC PGM=name)
would specify on the ATTACHX macro no shared subpools. Doesn't make
sense for a job step task to share any subpools with the higher job
step tasks.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: ICSF with CPACF (was RE: Encrypting tape drives... anyone considering field encryption?)

2006-09-10 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of R.S.
 Sent: Sunday, September 10, 2006 11:35 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: ICSF with CPACF (was RE: Encrypting tape drives... anyone
 considering field encryption?)
 
 Jeffrey D. Smith wrote:
 [...]
 How about key IMPORT ? Could I keep the key in encrypted form and import
 it from CKDS ?
 
  Of course, but you can't use CPACF in that case.
 I can use both: ICSF for key extract and CPACF.
 BTW: I understand using CPACF as using CPACF directly OR via ICSF API.

You can't decrypt the encrypted key. Therefore, you can't use CPACF with
ICSF encrypted key tokens.

 The RACF support in ICSF restricts access to the services, but not the
 resource being ciphered. That is a HUGE difference.
 
 RACF restrict acces to both services and keys as well.
 
  ICSF issues security calls for services and keys. That's not my point.
  ICSF does nothing to protect the ciphered resource. *Both* the ciphered
  resource and the key that ciphers it must be protected through a single
  point of access.
 Now I understand your point! You want to tie protection of key with
 protection of the resource. This is very interesting approach. However I
 cannot agree with the must keyword as a general rule. Why ???

Because that's the way a key management system works, by separation of
key type (usage) and binding keys to the resource protected by the key.

  I think there is a language barrier here. My point is that there is
  no point in preventing/restricting acccess to the ICSF ciphering
  functions. The vast majority of encryption needs involve ciphering
  data. With CPACF, there is no need to use ICSF. Thus, applying security
  controls to ICSF ciphering is useless. A program can directly use CPACF
  instead of ICSF.
 Even if CPACF would be unavailable, I don't think, that any function
 should be restricted. We don't restrict READ, but we control a dataset
 which can be read. Everyone can add, multiply, divide, etc. so why to
 deny encryption as a function ?

Well, you're the one who pointed out that ICSF can use RACF to restrict
access to its ciphering services, as well as access to the keys. Restricting
access to ciphering is somewhat useless. It's the keys combined with the
resources protected by the keys that need protection. ICSF doesn't do that.

 So, if you are forced to use a 3rd party key management system, you
 have
 no need for ICSF.
 
 Wrong assumption - maybe people are not forced to use 3rd party KMS.
 Sometimes people use ICSF with TKE workstation.
 
  TKE is not a key management *system*. It is a trusted key entry device.
  That has nothing to do with managing the use of keys.
 TKE is for key entry. Key entry is part of key management (this is
 matter of definition). Sometimes this part of key management is enough.
 Sometimes even TKE is not needed.

TKE is only for physical protection while entering clear keys into a
physically protected key storage unit. TKE is not anything near to being a
key management system. TKE has nothing to do with what happens with the keys
after the keys get inside the secure boundary. Many sites that use ICSF
ciphering don't need TKE. Also, there are many sites that use non-ICSF
ciphering and they rely solely on software security controls (or sometimes
post-it notes on the terminal) for access to the keys and the resources.

 Regards
 --
 Radoslaw Skorupka
/snip/

ICSF provides a key repository and a ciphering interface to older
cryptographic hardware that uses the hardware master key concept. ICSF
is not a key management *system*. If a site needs a KMS, then it must
buy or build one.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: ICSF with CPACF (was RE: Encrypting tape drives... anyone considering field encryption?)

2006-09-07 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of R.S.
 Sent: Thursday, September 07, 2006 1:22 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: ICSF with CPACF (was RE: Encrypting tape drives... anyone
 considering field encryption?)
 
 Jeffrey D. Smith wrote:
 [...]
 
 I dare to disagree. ICSF's CKDS is ready to use key container. The keys
 are encrypted using master key.
 
 
  Wrong. The CPACF services offered by ICSF require CLEAR KEYS. They are
  not encrypted by the master key. There are new key form keywords for
  clear keys, CLRDES for clear DES key and CLRAES for clear AES key.
  These are the only key forms usable by the CPACF interface in ICSF, and
  they are not encrypted anywhere, either in storage or on the CKDS.
 
 How about key IMPORT ? Could I keep the key in encrypted form and import
 it from CKDS ?
Of course, but you can't use CPACF in that case.

 Second thought: CKDS is (should be) well protected. No user, especially
 production support should have read access to it. Keys are read by ICSF
 STC user. Even that is better than nothing. Remember: we're talking here
 about *clear key functions* - such cryptography means your staff is able
 to read the key. It is not secure too much.
That's a given. Any key repository must be protected by a security
product, like IBM RACF. ICSF CKDS is no different in that respect.

 This is the advantage - you don't have
 to worry about it. You can control and audit key usage using RACF. The
 person who use key may be unable to read the key from storage (different
 set of authorities).
 
  The RACF support in ICSF restricts access to the services, but not the
  resource being ciphered. That is a HUGE difference.
 
 RACF restrict acces to both services and keys as well.
ICSF issues security calls for services and keys. That's not my point.
ICSF does nothing to protect the ciphered resource. *Both* the ciphered
resource and the key that ciphers it must be protected through a single
point of access.

 
 [...]
 A key management *system* is much more complex than what ICSF offers.
 
 Please enlight us:
 1. What is key management system?
 
  A key management system controls access to keys, rather than access to
  ciphering services.
 As I mentioned ICSF calls RACF for the keys usage as well.
But ICSF does not call the security product to determine whether the
key may applied to the resource.

 
  With CPACF, any problem program can perform ciphering.
  Restricting access to ciphering is missing the entire point of security.
 Nonsense! Why to limit access to ciphering functions ??? It is as
 pointless as restricting access to functions like ADD, DIVIDE etc. Using
 such commands I can implement encryption alghorithms in the software.
 Again, I see no reason to restrict the functions. Maybe except
 performance penalty.
I think there is a language barrier here. My point is that there is
no point in preventing/restricting acccess to the ICSF ciphering
functions. The vast majority of encryption needs involve ciphering
data. With CPACF, there is no need to use ICSF. Thus, applying security
controls to ICSF ciphering is useless. A program can directly use CPACF
instead of ICSF.

 
  Controlling and auditing access to keys that are bound to specific
 resources
  is the point of a secure key management system.
 
 RACF CL(CSFKEYS) again.
Again, that does nothing to protect/ensure that the ciphered resource
is being accessed properly. It does not to ensure that key is being
applied to the correct resource.

 
 2. Why do we need KMS, especially for clear key operations?
 
  The KMS prevents exposure of the keys to the application. The KMS can
 use
  the CPACF with clear keys in *protected* storage so that the end-user
 cannot
  exposure the clear keys. Thus, the benefits of performance and
 scalability
  of CPACF are complemented with secure key management. You don't get any
 of
  that with ICSF.
 
 Anaything in central storage is considered as susceptible to being read
 by a human. Such a person should have specific knowledge and system
 authorities. End user is absolutely unable to read the key from storage
 or read storage at all. System programmer can make a dump. CPACF does
 not offer protected storage - because it is central storage of CPC.
And ICSF now supports CLEAR keys in its own storage boundary, or within
an application storage boundary, and on the CKDS.

With proper security controls in place, no one can *force* exposure of
the clear keys.

 If you really want secure keys, you need to use crypto cards, CEX2C, or
 older PCIXCC, PCICC. This is in fact specialized computer, with PowerPC
 onboard and *it's own storage*. The storage is protected against
 tampering. Opening enclosure clears all the memory  registers making
 card clear and unusable.
Yes, we know all of that. This topic is focused on the CPACF and its
clear key usage, and how to manage keys.

There are plenty of sites that can operate satisfactorily

Re: ICSF with CPACF

2006-09-07 Thread Jeffrey D. Smith
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Alan Altmark
 Sent: Thursday, September 07, 2006 10:07 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: ICSF with CPACF
 
 On Thursday, 09/07/2006 at 08:12 CST, Jeffrey D. Smith
 [EMAIL PROTECTED] wrote:
  I think there is a language barrier here. My point is that there is
  no point in preventing/restricting acccess to the ICSF ciphering
  functions. The vast majority of encryption needs involve ciphering
  data. With CPACF, there is no need to use ICSF. Thus, applying security
  controls to ICSF ciphering is useless. A program can directly use CPACF
  instead of ICSF.
 
 I disagree on two points:
 1. ICSF is surrounded by Process and Privilege (PP) to get keys into,
 out of, share, etc..  If an application manages its own encryption key,
 then you have to create another instance of PP.  Yet another thing to be
 evaluated and audited in its own right.

Any key management system, whether IBM or an ISV, must be reviewed as to
whether it meets the needs of the site, including adequate security
administration protocols. A key management system must be an authorized
system service that binds access to the resource with access to the key
for that resource.

My main point is that ICSF is not a key management *system*, because it
doesn't correlate access to the key with access to the resource protected
by the key.

A key management system works the other way. When a program is authorized
to a resource through the security product, for a particular kind of access
(like reading clear data), then access to the deciphering key is also
authorized at the same time. The application program never sees both the
enciphered data and the deciphered data, and it never sees the deciphering
key. A trusted server verifies the access request, and delivers the
deciphered data to the program application.

 2. If the application is using CPACF directly, then the clear key is in
 application memory and is vulnerable to a hacked application and is
 visible in address space dumps.

Same with ICSF using CPACF. The clear keys are in its application storage
and could be exposed through a dump or hacking.

  And ICSF now supports CLEAR keys in its own storage boundary, or within
  an application storage boundary, and on the CKDS.
 
 Only a supervisor state application can extract the clear keys from ICSF
 for its own use with CPACF.  Normal applications cannot get to the keys,
 encrypted or not.

I didn't make that distinction clear enough. Authorized programs are
*trusted programs*. Deciding which programs can be authorized is a
policy decision outside of the cryptographic service software. Operational
keys must be isolated away from unauthorized application programs.

  With proper security controls in place, no one can *force* exposure of
  the clear keys.
 
 If you have clear keys on your system, be sure to encrypt the backups of
 the CKDS/PKDS/or any other file that contains them!  :-)

 Alan Altmark
 z/VM Development
 IBM Endicott
/snip/

I really don't like the idea of storing clear keys in data sets. At most,
only one key, the master key, must be maintained in the clear somewhere
(hopefully not on a post-it note pasted to the security admin's terminal).

The master key concept distinguishes the master key from all other key
types. The master key encrypts a (small) set of other keys, which are
then used to encrypt other keys. This forms a hierarchy of encrypted
keys, which prevents cross-contamination between logically distinct
business organizations.

The master key (or key parts or pass phrase) must be stored in the clear
somewhere and protected by means other than encryption. All other keys
should be encrypted when stored in a data set. When the key is in central
storage for use, it should be within a secure boundary protected either by
hardware or by the operating system services for authorized programs.

The key management system only has access to the master key and to a very
limited set of top-level key-encrypting keys (KEKs). After those keys
are imported into the KMS, then other business organizations using their
own secure access to their encrypted key repositories can import the keys
into the KMS. A KMS never has direct access to all of the encrypted key
repositories on DASD.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


  1   2   >