Re: COBOL packed decimal
My dad worked on the 1108 II, I think at Ft. Harrison in Indy Scott ford www.identityforge.com On Jul 21, 2012, at 9:26 AM, John Gilmore jwgli...@gmail.com wrote: The Unisys 1108, a (36-bit) word machine, was originally the UNIVAC 1108 I (circa 1965) and the UNIVAC 1108 II (circa 1968); and UNIVAC was at that time a division of Sperry Rand. John Gilmore, Ashland, MA, 01721 - USA On 7/20/12, Scott Ford scott_j_f...@yahoo.com wrote: Shmuel, Who did the inherit the 1108 from ? My dad worked for Unisys on the 1108sdude Scott ford www.identityforge.com On Jul 20, 2012, at 11:43 AM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In 9307538697441482.wa.paulgboulderaim@listserv.ua.edu, on 07/19/2012 at 09:22 AM, Paul Gilmartin paulgboul...@aim.com said: Is this because Unisys is deficient in conformance to the standard, or because IBM's implementation contains an extension to the standard? No, it's because UNIVAC used ones complement arithmetic on most of its lines, Including the 1108 et al that Unisys inherited. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL packed decimal
In c4c6c378-b640-43a1-88d5-7c79f3bf0...@yahoo.com, on 07/20/2012 at 08:08 PM, Scott Ford scott_j_f...@yahoo.com said: Who did the inherit the 1108 from ? My dad worked for Unisys on the 1108sdude Unisys was a merger of Burroughs and UNIVAC; They kept the B6500 line from Burroughs and the 1100[1] line from UNIVAC. [1] The 1108, 1110, 1106 and successors; not the 1103 or 1105. I'm not sure whether you want to count the 1107 as part of that line, but it was certainly the father of the 1108. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL packed decimal
In 1342898015.24312.yahoomail...@web164504.mail.gq1.yahoo.com, on 07/21/2012 at 12:13 PM, Scott Ford scott_j_f...@yahoo.com said: I wasnt sure if the 1108 had come from RCA or Buroughs The 1108 dates back to the old Remington-Rand or Sperry Rand, not to the RCA EDP acquisition. It's possible that Unisys picked up the RCA Spectra 70, but that's a very different series. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
Paul Gilmartin wrote:
On Fri, 20 Jul 2012 07:31:09 +0100, CM Poncelet wrote:
I did explain that ISREDIT follows Clist rules when processing 's, in
my earlier posting, methinks grin:
...
TSO Clist edit macros have been around long before REXX appeared (around
1989-90) and ISREDIT was meant to be called in Clist, not REXX.. So REXX
has to follow the Clist rules when calling ISREDIT - e.g. to process
data containing 's.
Does this mean that if the same command string is issued to ISREDIT
from CLIST and from Rexx the effect will be identical, or not?
In most cases yes - unless there are ampersands in the string. In Clist,
3 's must be coded. But it seems like 2 's are enough in REXX (I have
not checked what happens if 3 's are coded in REXX).
I scarcely know CLIST. Is it even meaningful to discuss the command
string issued from CLIST to ISREDIT?
It is meaningful only when ISREDIT command strings issued from REXX do
not produce the expected 'REXX-like' results.
How old is the CALL interface from programming languages?
I do not know, but either it or something like it was around for
'executing' Clist from PL/I in the 1980's. However, it is more efficient
CPU-wise to call a load module from REXX/Clist (e.g. in a loop) and
perform whatever needs to be done by REXX/Clist in the calling
REXX/Clist code itself, rather than execute a load module first and have
it then call REXX/Clist for whatever it needs.
Same
question as earlier: Do identical command strings issued to ISREDIT
from CLIST and CALL have identical effect?
I would expect the ISREDIT effects of REXX/Clist v. ISPLINK calls to be
identical, because the command strings in the call are passed as data
constants.
How are ampersands
treated in commands passed via CALL?
If you are referring to ISPLINK, the ampersands would be passed together
with all the other characters in the string. The assembler (or compiler)
cannot interpret the meaning/purpose of the REXX/Clist strings to
convert them into efficient machine code. So it assembles/compiles its
own program code, which it recognizes, but leaves the REXX/Clist strings
as they are and passes them as data in the call.
As you imply Rexx is not
CLIST. Might it not have been better if the Rexx interface had been
specified as CALL-like rather than CLIST-like?
Unless I misunderstand what you mean by 'CALL-like', REXX is calling
ISREDIT - as the strings are enclosed in quotes (e.g. ISREDIT FIND
whatever). It is ISREDIT, not the REXX interface, which interprets an
ampersand-prefix as a variable (like Clist does). I suspect that this is
because edit macros were originally written in Clist, before REXX
appeared, and ISREDIT follows Clist rules because of that.
There is nothing wrong with ISPF itself.
That's a sweeping statement. Are you sure?
I meant it within the context of using 'FIND' in ISPF itself, instead of
via ISREDIT. If you copy/paste all the JCL PROC lines from the original
post (e.g. into a member of a PDS) and then, from the command line,
issue FIND FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)',
ISPF's EDIT will then position its cursor on the first line that
contains that string and also at the first character of that string; if
you hit RFIND, it will find the next occurrence etc.; ditto for all the
other FIND strings in the edit macro. If you then save that member and
BROWSE it, and repeat all the FINDs, ISPF's BROWSE will each time
position the cursor at the correct line and starting character of the
string. So ISPF is not itself causing the edit macro problems. If you
then write some REXX to ALLOCATE FI(IN) DA('whatever the DSN(member)
is') SHR KEEP, EXECIO * DISKR IN (STEM REC. FINIS), then loop
through a 'SAY REC.*' to display the lines read in - and save/execute
this REXX - all the lines will be displayed exactly as they are in the
PDS member and with their ampersands etc. So REXX is not causing the
edit macro problems either. Therefore ISREDIT is causing them.
Apart from that, there are lots of things wrong with ISPF (starting from
ESA onwards and getting worse); but that is way 'off topic'.
Cheers.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: re-entrant modules and the binder
I am not sure that I fully understand exactly what you want to do or the exact sequence in which you want to do it. Your objective is, however, clear: You want to be able to use the CICS RENTPGM=PROTECT facility. If 1) you specify this option for a CICS application program (AP) and 2) CICS honors it, that AP is placed in read-only storage. A later attempt to execute such an AP will have dire consequences if it in fact modifies itself. You may not therefore specify this option for a load module or program object that contains a non-reentrant assembly-language module or modules. As you have noted, there is no great difficulty about making your COBOL modules reentrant. Instructing your compiler to do so will accomplish this. Specifying the RENT option when you assemble your HLASM subroutines instructs the HLASM to check your code for non-reentrant constructs, and it finds many but not quite all of them. (You can and should use the SYSOPT_RENT boolean within each assembly unit to ensure that the RENT option has in fact been specified for it.) I strongly recommend that you also make these assembly-language modules LE-compatible. Using the LE's LIFO storage-management facilities will make the task of making these modules reentrant much easier. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL packed decimal
I was aware of the hardware on the machines, since my late father was a FE on them. Didn't really know anything about the opsys or programming languages. So the history is very interesting Scott ford www.identityforge.com On Jul 22, 2012, at 8:37 AM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In 1342898015.24312.yahoomail...@web164504.mail.gq1.yahoo.com, on 07/21/2012 at 12:13 PM, Scott Ford scott_j_f...@yahoo.com said: I wasnt sure if the 1108 had come from RCA or Buroughs The 1108 dates back to the old Remington-Rand or Sperry Rand, not to the RCA EDP acquisition. It's possible that Unisys picked up the RCA Spectra 70, but that's a very different series. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: re-entrant modules and the binder
and it finds many but not quite all of them. Basically, it finds ST 1,FOO where FOO is defined in the CSECT something like FOO DC F'0' but it does not find things like the following construct that IBM macros are or were fond of CNOP 0,4 BAL 1,*+8 DCF'0' ST2,0(0,1) In the first case it knows that FOO is in a code section but in the latter it only knows that R1 is pointing somewhere. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Sunday, July 22, 2012 6:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: re-entrant modules and the binder I am not sure that I fully understand exactly what you want to do or the exact sequence in which you want to do it. Your objective is, however, clear: You want to be able to use the CICS RENTPGM=PROTECT facility. If 1) you specify this option for a CICS application program (AP) and 2) CICS honors it, that AP is placed in read-only storage. A later attempt to execute such an AP will have dire consequences if it in fact modifies itself. You may not therefore specify this option for a load module or program object that contains a non-reentrant assembly-language module or modules. As you have noted, there is no great difficulty about making your COBOL modules reentrant. Instructing your compiler to do so will accomplish this. Specifying the RENT option when you assemble your HLASM subroutines instructs the HLASM to check your code for non-reentrant constructs, and it finds many but not quite all of them. (You can and should use the SYSOPT_RENT boolean within each assembly unit to ensure that the RENT option has in fact been specified for it.) I strongly recommend that you also make these assembly-language modules LE-compatible. Using the LE's LIFO storage-management facilities will make the task of making these modules reentrant much easier. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
On Sun, 22 Jul 2012 13:50:25 +0100, CM Poncelet wrote: Same question as earlier: Do identical command strings issued to ISREDIT from CLIST and CALL have identical effect? I would expect the ISREDIT effects of REXX/Clist v. ISPLINK calls to be identical, because the command strings in the call are passed as data constants. But if issuing identical commands issued from Rexx vis-a-vis CLIST produce different results, the result from ISPLINK must differ from at least one of them. I suppose I can consider myself blessed never to have encountered this problem, possibly because I have never attempted a FIND command containing an ampersand. I shall continue to strive to avoid doing so. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
On Sun, 22 Jul 2012 15:17:11 -0500, David Boyes wrote: For those of you who haven't seen it, VM, VSE and Linux register for a specific fully-architected hardware external interrupt (in the PoPs) that indicates that the LPAR is being shut down. VSE issues a message, VM reflects the interrupt to all virtual machines which are registered to receive it, and Linux (if configured to register for it) triggers a user-specified command (usually 'shutdown -h now'). I'd like to have z/OS register for that interrupt, and at least print a unique message if/when that specific interrupt arrives. In Linux, which process handles the shutdown signal? Init? Or is it sent to all processes with a default of ignore, with at least one superuser process handling it by issuing shutdown? Some years ago, I suggested in MVS-OE that MVS shutdown should send SIGTERM to all dubbed processes so that processes coded to UNIX conventions could perform orderly shutdown. The suggestion was not well received. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
On Sun, 22 Jul 2012 18:23:36 -0400, zMan wrote: Some years ago, I suggested in MVS-OE that MVS shutdown should send SIGTERM to all dubbed processes so that processes coded to UNIX conventions could perform orderly shutdown. The suggestion was not well received. Can you elaborate? Why would orderly shutdown not be A Good Thing? They didn't say. Too UNIXy for them. But I'll conjecture: Many address spaces get dubbed nowadays by incidental use of UNIX services such as TCP/IP. The default action for SIGTERM if a process doesn't handle it is that the process is terminated. This would be unwelcomed by a process that was waiting rather for a legacy MODIFY command to shut itself down. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
Gil, I am with you and zMan what's so difficult about an orderly shutdown on OMVS and z/os address spaces..z/Pdt has vtamappl, everything shutdown fine... Scott ford www.identityforge.com On Jul 22, 2012, at 6:37 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Sun, 22 Jul 2012 18:23:36 -0400, zMan wrote: Some years ago, I suggested in MVS-OE that MVS shutdown should send SIGTERM to all dubbed processes so that processes coded to UNIX conventions could perform orderly shutdown. The suggestion was not well received. Can you elaborate? Why would orderly shutdown not be A Good Thing? They didn't say. Too UNIXy for them. But I'll conjecture: Many address spaces get dubbed nowadays by incidental use of UNIX services such as TCP/IP. The default action for SIGTERM if a process doesn't handle it is that the process is terminated. This would be unwelcomed by a process that was waiting rather for a legacy MODIFY command to shut itself down. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
I think the problem is that in z/OS there is no one way of notification (I know you are asking for one). There are at least 2 (3 if you count z) commands to stop an application, P and ,technically F I know F is usually modify but it is also used as stop. All the applications would have to be re-written. An interface would have to be created (again programs would have to be altered and or re- written). I am not against it per se it would be a few years to implement I am sure. Plus there is an issue of timing on how things happen. I smell an ugly up rising. Ed On Jul 22, 2012, at 5:45 PM, Scott Ford wrote: Gil, I am with you and zMan what's so difficult about an orderly shutdown on OMVS and z/os address spaces..z/Pdt has vtamappl, everything shutdown fine... Scott ford www.identityforge.com On Jul 22, 2012, at 6:37 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Sun, 22 Jul 2012 18:23:36 -0400, zMan wrote: Some years ago, I suggested in MVS-OE that MVS shutdown should send SIGTERM to all dubbed processes so that processes coded to UNIX conventions could perform orderly shutdown. The suggestion was not well received. Can you elaborate? Why would orderly shutdown not be A Good Thing? They didn't say. Too UNIXy for them. But I'll conjecture: Many address spaces get dubbed nowadays by incidental use of UNIX services such as TCP/IP. The default action for SIGTERM if a process doesn't handle it is that the process is terminated. This would be unwelcomed by a process that was waiting rather for a legacy MODIFY command to shut itself down. -- gil - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM- MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
How can I go about submitting a requirement for z/OS to acknowledge and handle the same external interrupt as VM, VSE and Linux use to trigger a controlled shutdown (or at least acknowledge it by printing a message we can capture via console automation and trigger the shutdown ourselves)? David, the best way to submit a requirement is through Share. Anyone can submit a requirement. Share has a new website that you'll need to sign up for, but you don't have to be a Share member. http://reqs4.share.org/Reqs4Who.jsp is the link to the requirements system. You can also submit a MR (Marketing Requirement) through your IBM Rep. IBM has had a renewed focus on Share requirements over the last couple of years. If you need assistance, please feel free to contact me off list. Mary Anne -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
David, What issuing a z/Pdt cmd OPRMSG 'cmd ...'. Scott ford www.identityforge.com On Jul 22, 2012, at 4:17 PM, David Boyes dbo...@sinenomine.net wrote: How can I go about submitting a requirement for z/OS to acknowledge and handle the same external interrupt as VM, VSE and Linux use to trigger a controlled shutdown (or at least acknowledge it by printing a message we can capture via console automation and trigger the shutdown ourselves)? For those of you who haven't seen it, VM, VSE and Linux register for a specific fully-architected hardware external interrupt (in the PoPs) that indicates that the LPAR is being shut down. VSE issues a message, VM reflects the interrupt to all virtual machines which are registered to receive it, and Linux (if configured to register for it) triggers a user-specified command (usually 'shutdown -h now'). I'd like to have z/OS register for that interrupt, and at least print a unique message if/when that specific interrupt arrives. Any suggestions on how to get this done without taking decades? It doesn't seem like a lot to ask for, and it's a fully-defined legitimate hardware interrupt that z/OS ought to be able to handle if it got one. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
At 18:18 -0500 on 07/22/2012, Ed Gould wrote about Re: Submitting a requirement for z/OS to at least acknowled: I think the problem is that in z/OS there is no one way of notification (I know you are asking for one). There are at least 2 (3 if you count z) commands to stop an application, P and ,technically F I know F is usually modify but it is also used as stop. All the applications would have to be re-written. An interface would have to be created (again programs would have to be altered and or re-written). I am not against it per se it would be a few years to implement I am sure. Plus there is an issue of timing on how things happen. I smell an ugly up rising. Ed I do not think that he is requesting that the interrupt has to trigger a MVS Shut-Down - Only that when the interrupt occurs that the system acknowledge that it has occurred and respond to it somehow. A suggestion in his request was that a console message be issued to alert the operator and (if one exists) the message handling operations package. The Message would go to the master consoles and would be flagged as non-scrollable. That meets he defined request. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
Robert, That is my understanding also..as long as an automation package or maybe even system rexx could intercept the message and take action that was desired. I don't see why that wouldn't work... Scott ford www.identityforge.com On Jul 22, 2012, at 8:51 PM, Robert A. Rosenberg hal9...@panix.com wrote: At 18:18 -0500 on 07/22/2012, Ed Gould wrote about Re: Submitting a requirement for z/OS to at least acknowled: I think the problem is that in z/OS there is no one way of notification (I know you are asking for one). There are at least 2 (3 if you count z) commands to stop an application, P and ,technically F I know F is usually modify but it is also used as stop. All the applications would have to be re-written. An interface would have to be created (again programs would have to be altered and or re-written). I am not against it per se it would be a few years to implement I am sure. Plus there is an issue of timing on how things happen. I smell an ugly up rising. Ed I do not think that he is requesting that the interrupt has to trigger a MVS Shut-Down - Only that when the interrupt occurs that the system acknowledge that it has occurred and respond to it somehow. A suggestion in his request was that a console message be issued to alert the operator and (if one exists) the message handling operations package. The Message would go to the master consoles and would be flagged as non-scrollable. That meets he defined request. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Integrating User Identity
Peter, could you elaborate on what integration means to you? Thanks. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Shmuel Metz asks: There is support for mapping long user ids into short user ids. Does that support work if the access validation is in a third party LDAP server? Base z/OS includes LDAP client support, provided in the Tivoli Directory Server for z/OS. I already answered yes, so I'll vote yes again. :-) 2. Note that you are not required to use TSO/E user IDs as user IDs. You are if you want to log on to TSO foreground, which is what I asked about. You perhaps missed my point there. You can consider TSO/E user IDs to be tokens in a pool if you wish, and they may or may not be unique per individual. That's a policy and implementation question which your organization gets to decide. But I explicitly asked about TSO. The original poster didn't make that clear. I did. Scott Ford adds: Sales pitch, sorry guys...I will bet there are thousands and thousands of users using either TSO or CMS ..of course CICS and IMS and DB2 ...we also sell software ...LDAP ...but I won't go there unless its offline. This isn't the place to try to hustle ppl If that comment was aimed at me, it was not well aimed. The only thing I've been doing is suggesting solutions, most or all of which happen to require nothing but what you have in z/OS. Let me repeat: *everybody* who licenses *base* z/OS gets IBM's LDAP server and client. OK, so if this -- enhanced (or at least different) authentication and/or authorization for TSO/E applications -- isn't a real problem for you, fine, you can ignore this thread. Alternatively, if you don't like my proposed solutions, send IBM a formal enhancement request through the proper channels along with your suggested solution design. Feel free to borrow my suggestions if you like them. No royalties are required. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help with elementary CPU speed question
Mike Ward writes: This is one area where I really have a problem. It used to be back in the 370 days that if a machine was rated at 50 mips and you moved up to 100 mips you really noticed the difference in execution time I know I'm on a rant Was there even a 100 MIPS uniprocessor model in the 370 days? I don't know, but I know that less than 12 years ago the uniprocessor z900 was a bit under 200 MIPS, and that was considered a fast machine. (And hasn't it been a fantastic decade for mainframe core performance!) There's tremendous flexibility in capacity configurations nowadays -- much more than in the past. If you want fewer, taller engines, that's available. Or the opposite. Or several somethings in between, in general. You can choose whatever works best. That said, with 80-way single machines available, the multiprocessor bridge is now well crossed. :-) I recommend taking steps to tweak and to improve workloads so that they aren't unduly burdened by the limits of single core performance. Goodness knows IBM has done a lot of work in that area. CICS Transaction Server is an excellent example among many. There are limits in improvements and tweaks, of course. But better is still better. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage utililzation Optimization
Compression is also an option -- in DB2, for example -- if you're not using it. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: re-entrant modules and the binder
At 09:13 -0700 on 07/22/2012, Charles Mills wrote about Re: re-entrant modules and the binder: and it finds many but not quite all of them. Basically, it finds ST 1,FOO where FOO is defined in the CSECT something like FOO DC F'0' but it does not find things like the following construct that IBM macros are or were fond of CNOP 0,4 BAL 1,*+8 DCF'0' ST2,0(0,1) In the first case it knows that FOO is in a code section but in the latter it only knows that R1 is pointing somewhere. Charles Since these modules are intended for use with CICS, most of the IBM macros that would fool the RENT Check are going to be ones that should not be being used in the first place. For example, doing I/O (and thus using OPEN/CLOSE and I/O calls) is not something you are supposed to do under CICS (you use the CICS not the OS support). What is the the intent of the Assembler Routines? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NFS Client Start Delay
Hello, After spending more time on this issue, I have realized that this delay is because of syslog was consuming all spaced allocated to that. So, I have deleted syslog file from /usr/local/logs. This resolved my issue. Thanks for help. Regards Saurabh On Fri, Jul 6, 2012 at 9:14 PM, Skip Robinson jo.skip.robin...@sce.comwrote: Delay cause seems to be crucial here. I haven't seen anyone comment on what I consider to be OP's unusual configuration. If I understand the original post, two out of three 'sysplex' members are parallel while the other is not. If that's so, then two members have access to coupling facility structures while the other has only CTC connections to the other two. In reading over the paragraph above, I think I must have misunderstood. Can you even run that way? We have several parallel sysplexes, one basic (no CF) sysplex, and some monoplexes. They are and I think must be entirely separate plexes. I would have thought that any nonparallel system in a complex must not attempt to share resources with an adjacent parallel sysplex. If that's true, then this is a two-system problem; the third system is irrelevant. Or am I being naïve? . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Doug Henry doug_he...@usbank.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/06/2012 07:47 AM Subject:Re: NFS Client Start Delay Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Fri, 6 Jul 2012 07:35:27 +0530, saurabh khandelwal sourabhkhandelwal...@gmail.com wrote: I started NFS client at 23.35.45 but it actually started at 00.10.15e. So, it took more then 30 min to start. Not sure, why this is happening. Is there any thing to do with parallel sysplex or something else. 1) D OMVS,W BPXO063I 00.07.36 DISPLAY OMVS 142 OMVS 000E ETC/INIT WAIT OMVS=(05,FS) Hi Saurabh, Maybe you already know this but the BPXO0631I message shows the problem. You haven't finished your OMVS INIT. See: z/OS V1R13.0 UNIX System Services Planning 13.7.8 Diagnosing hangs during z/OS UNIX initialization Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN Digest - 21 Jul 2012 to 22 Jul 2012 (#2012-204)
In Linux, which process handles the shutdown signal? Init? Or is it sent to all processes with a default of ignore, with at least one superuser process handling it by issuing shutdown? They hooked it into init (believe it or not, into the cntl-alt-del handler...). The kernel registers for the hardware signal, and triggers that event. You define what you want it to do in /etc/inittab (default is 'shutdown -h now'). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Sorry we are competitors I won't say more Scott ford www.identityforge.com On Jul 22, 2012, at 8:38 PM, Timothy Sipples timothy.sipp...@us.ibm.com wrote: Shmuel Metz asks: There is support for mapping long user ids into short user ids. Does that support work if the access validation is in a third party LDAP server? Base z/OS includes LDAP client support, provided in the Tivoli Directory Server for z/OS. I already answered yes, so I'll vote yes again. :-) 2. Note that you are not required to use TSO/E user IDs as user IDs. You are if you want to log on to TSO foreground, which is what I asked about. You perhaps missed my point there. You can consider TSO/E user IDs to be tokens in a pool if you wish, and they may or may not be unique per individual. That's a policy and implementation question which your organization gets to decide. But I explicitly asked about TSO. The original poster didn't make that clear. I did. Scott Ford adds: Sales pitch, sorry guys...I will bet there are thousands and thousands of users using either TSO or CMS ..of course CICS and IMS and DB2 ...we also sell software ...LDAP ...but I won't go there unless its offline. This isn't the place to try to hustle ppl If that comment was aimed at me, it was not well aimed. The only thing I've been doing is suggesting solutions, most or all of which happen to require nothing but what you have in z/OS. Let me repeat: *everybody* who licenses *base* z/OS gets IBM's LDAP server and client. OK, so if this -- enhanced (or at least different) authentication and/or authorization for TSO/E applications -- isn't a real problem for you, fine, you can ignore this thread. Alternatively, if you don't like my proposed solutions, send IBM a formal enhancement request through the proper channels along with your suggested solution design. Feel free to borrow my suggestions if you like them. No royalties are required. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
