Re: JES/2 Spool
Our SyzSPOOL/z (WWW.SyzygyInc.com/SyzSpool.htm) product does exactly what you are looking for, and while it's not free, it's pretty close. It's available to IBMMain participants for 50% off the regular price (which is already low), so for about $2,500 you get spool management and access to the spool data via ISPF or the WWW. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OS/390 CD collection free to a good home
retired mainframer wrote: I have the complete 9 CD Online Library OS/390 Collection, dated September 1998, SK2T-6700-10. If anyone has any use for it, I will gladly mail them the CDs and the IBM binder. I will wait a week or so for off-line responses before contributing them to the city land-fill. Donate it to a computer museum. There are lurkers on IBM-MAIN who are representing them. Perhaps they will contact you off-list. Sorry, I don't have any links of them for now... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
static const arrays in C
Hello all,
we have some modules written in C that have large arrays with constants.
For some reasons we are forced to compile those modules using the RENT
compiler option, which moves those arrays to the WSA (writable storage
area)
at runtime, which is not a desired behaviour, because this way, the
storage is
occupied twice - once ín the WSA and second in the initialization area
in the
STATIC CSECT - and there is coding needed at startup to move the constants
into the WSA.
We are not able to move to NORENT due to site conventions.
Now my question: is it sufficient to mark those arrays with the const
attribute,
that is
static const double tab [10] = { ... values follow ... };
or are there special #pragmas needed to prevent this table from being
moved to the WSA, given the RENT compiler option?
Kind regards
Bernd
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: static const arrays in C
What the ANSI standard says.
On Fri, 24 Aug 2012 12:37:05 +0200, Bernd Oppolzer wrote:
we have some modules written in C that have large arrays with constants.
For some reasons we are forced to compile those modules using the RENT
compiler option, which moves those arrays to the WSA (writable storage
area)
at runtime, which is not a desired behaviour, because this way, the
storage is
occupied twice - once �n the WSA and second in the initialization area
in the
STATIC CSECT - and there is coding needed at startup to move the constants
into the WSA.
We are not able to move to NORENT due to site conventions.
Now my question: is it sufficient to mark those arrays with the const
attribute,
that is
static const double tab [10] = { ... values follow ... };
or are there special #pragmas needed to prevent this table from being
moved to the WSA, given the RENT compiler option?
Years ago, I investigated such behavior with an ISV compiler, not
IBM's. In that case, yes, if an object was declared const it was not
moved to writable storage area. I looked further at the ANSI
standard which says, IIRC, that if an object is declared const in
one translation unit and declared not const in another translation
unit (of course you would _never_ do that), and the latter modifies
the object, the result is undefined. It stated no restriction if the
object is never modified. I concluded that the ISV compiler might
be stretching the standard by allowing the two translation units to
refer to different instances of the object. I didn't press the point.
But an object declared static shouldn't be accessible by name
from more than one translation unit.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: static const arrays in C
I think I found the answer myself.
Using the compiler option ROCONST (which is NOT the default with C
programs),
you can specify that variables with the const attribute not be moved to
the WSA - that
is, the const attribute is respected. Otherwise (NOROCONST) it is ignored.
This is the default with C (not with C++).
Another way is using #pragma variable (variable_name, norent) for every
such large
read-only table, which has the same effect.
Any further suggestions?
Thank you, have a nice day and weekend.
Bernd
Am 24.08.2012 12:37, schrieb Bernd Oppolzer:
Hello all,
we have some modules written in C that have large arrays with constants.
For some reasons we are forced to compile those modules using the RENT
compiler option, which moves those arrays to the WSA (writable storage
area)
at runtime, which is not a desired behaviour, because this way, the
storage is
occupied twice - once ín the WSA and second in the initialization area
in the
STATIC CSECT - and there is coding needed at startup to move the
constants
into the WSA.
We are not able to move to NORENT due to site conventions.
Now my question: is it sufficient to mark those arrays with the const
attribute,
that is
static const double tab [10] = { ... values follow ... };
or are there special #pragmas needed to prevent this table from being
moved to the WSA, given the RENT compiler option?
Kind regards
Bernd
--
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: Documenting SMS environment ACS routines.
Thanks for that LISTPRT pointer. I used it to create data sets with that data. That will make it easier to include in my documentation. Of course, doing so will almost guarantee that the documentation will become obsolete. We're not too good on keeping our documentation up to date. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Thursday, August 23, 2012 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Documenting SMS environment ACS routines. ISMF options 3, 4, 5, and 6 have the LSTPRT command to document the properties of every data class, management class, storage class, and storage group. Option 7 can identify from where each of the ACS routines was compiled so you can find the source if it still exists. It can also identify any test cases your storage admin used when he developed the system. The D SMS system command can display the status of each storage group and the volumes in that group. Unfortunately, none of this will give you the philosophy or rationale of why things are this way. You will have to infer that based on your understanding of your business environment and anything you know about the admin himself. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On :: Behalf Of McKown, John :: Sent: Thursday, August 23, 2012 10:35 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Documenting SMS environment ACS routines. :: :: We have a rather fragile SMS environment at present. It has basically :: grown ad hoc over the course of almost 2 decades. I really need to :: document it very well. Once documented, I would like to use that in :: order to reengineer the environment. Any pointers would be greatly :: appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: static const arrays in C
This is interesting, but no problem in my special case, since the
large tables are inside a function and are not visible to outside callers.
So there can be no mixture of const and no-const.
The outside callers specify key information, the function looks up the
relevant information in the large tables (which is supposed to be
handled very fast),
and then the answer is returned through the function interface.
We also have slower and yet larger tables, which reside in files or DB
tables
(or data spaces using some third party piece of management software),
but those fast tables are used very often during computation;
the application is insurance math.
Kind regards
Bernd
Am 24.08.2012 14:40, schrieb Paul Gilmartin:
What the ANSI standard says.
On Fri, 24 Aug 2012 12:37:05 +0200, Bernd Oppolzer wrote:
we have some modules written in C that have large arrays with constants.
For some reasons we are forced to compile those modules using the RENT
compiler option, which moves those arrays to the WSA (writable storage
area)
at runtime, which is not a desired behaviour, because this way, the
storage is
occupied twice - once �n the WSA and second in the initialization area
in the
STATIC CSECT - and there is coding needed at startup to move the constants
into the WSA.
We are not able to move to NORENT due to site conventions.
Now my question: is it sufficient to mark those arrays with the const
attribute,
that is
static const double tab [10] = { ... values follow ... };
or are there special #pragmas needed to prevent this table from being
moved to the WSA, given the RENT compiler option?
Years ago, I investigated such behavior with an ISV compiler, not
IBM's. In that case, yes, if an object was declared const it was not
moved to writable storage area. I looked further at the ANSI
standard which says, IIRC, that if an object is declared const in
one translation unit and declared not const in another translation
unit (of course you would _never_ do that), and the latter modifies
the object, the result is undefined. It stated no restriction if the
object is never modified. I concluded that the ISV compiler might
be stretching the standard by allowing the two translation units to
refer to different instances of the object. I didn't press the point.
But an object declared static shouldn't be accessible by name
from more than one translation unit.
-- 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: static const arrays in C
Make initializers page-aligned? On Fri, 24 Aug 2012 14:41:16 +0200, Bernd Oppolzer wrote: Using the compiler option ROCONST (which is NOT the default with C programs), ... to avoid treading, however lightly, on the ANSI standard. you can specify that variables with the const attribute not be moved to the WSA - that is, the const attribute is respected. Otherwise (NOROCONST) it is ignored. This is the default with C (not with C++). I suspect const is not entirely ignored. Won't the compiler warn you if you modify, or even threaten to modify, a const object? But is it moved to WSA even if it's declared static const? There would seem to be no reason for that. Another way is using #pragma variable (variable_name, norent) for every such large read-only table, which has the same effect. Any further suggestions? No, but it occurs to me that a #pragma to page-align the initial values so the storage could be reclaimed once initialization is complete might be valuable. This might even be reasonable default behavior. Even better if numerous small initializers could be gather-loaded into a disposable page. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How often do you review your CFRM Policy?
Roger, I definitely would not make a change like this by itself. And I probably wouldn't make it even if I were making another change. If it ain't broke, don't fix it would be why. I don't really check the policy either. I attend SHARE psx sessions, and if I see something I think we should be doing, I'll come home, investigate, and decide whether or not to implement it. The last two changes I recall were in 2009, msgbased and duplexing. If there were holddata, I would of course, implement that. Sizing for CF Structures is done on an ongoing basis. There are three or four changes per year, mostly based on healthchecks. MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: static const arrays in C
Am 24.08.2012 15:11, schrieb Paul Gilmartin: Otherwise (NOROCONST) it is ignored. This is the default with C (not with C++). I suspect const is not entirely ignored. Won't the compiler warn you if you modify, or even threaten to modify, a const object? But is it moved to WSA even if it's declared static const? There would seem to be no reason for that. If I read the books correctly, if the options RENT and NOROCONST are in effect, then yes, the arrays are moved to the WSA even if const is specified. From the description of #pragma variable in the z/OS 1.10 XL C/C++ Language Reference, section 18.5.46: C only. To specify that variables declared as const not be placed into the writeable static area, *you must use the ROCONST and RENT compiler options. * Kind regards Bernd* * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yearlong DBA contract - State of AZ/Phoenix
On 8/24/2012 6:25 AM, Kerneels wrote: Anybody want to go to Phoenix because I use to work for this type of money 40 years ago ? Kerneels Original Message Subject:RE: Yearlong DBA contract - State of AZ/Phoenix Date: Thu, 23 Aug 2012 11:28:43 -0700 From: Ken Ekman ken.ek...@bakerit.com Reply-To: ken.ek...@bakerit.com Organization: BakerIT To: kerne...@absoftwareconsultants.com Kerneels, $47/hr w-2 or $54 C2C. Can that work (we have to stay in State guidelines…Ken *From:*Kerneels [mailto:kerne...@absoftwareconsultants.com] *Sent:* Thursday, August 23, 2012 11:25 AM *To:* Ken Ekman *Subject:* Re: Yearlong DBA contract - State of AZ/Phoenix What type of money are we talking about here ? Kerneels --- On *Thu, 8/23/12, Ken Ekman /ken.ek...@bakerit.com mailto:ken.ek...@bakerit.com/* wrote: From: Ken Ekman ken.ek...@bakerit.com mailto:ken.ek...@bakerit.com Subject: Yearlong DBA contract - State of AZ/Phoenix To: kerneels_br...@yahoo.com mailto:anton_br...@yahoo.com Date: Thursday, August 23, 2012, 12:16 PM 08/23/12 1:15 PM Greetings Kerneels, My name is Ken Ekman and I'm a recruiter at Baker IT. Our records show that you are a very experienced professional with a very good professional record in the IBM market place. The opening is located in *Phoenix, AZ. Job Title: DBA - Contract - State of AZ* Job Description: *Department of Economic Security* *Division of Technology Services* *EDP Database Specialist III* ** The Division of Technology Services (DTS), the primary provider of I.T. services within DES has a need to fill one contract EDP Data Base Specialist III. The individual must have skills as outlined below and in the required KSA and Desired Candidate sections. We anticipate this to be a 6 months to 1 year contract. The Arizona Department of Economic Security (DES) is host to a large IBM Z196 Mainframe, running z/OS 1.10 and 50+ discreet Transaction Server Systems Customer Information Control System (CICS) that support the majority of the Departments critical application systems. Each of these application systems must interface successfully with the z/OS operating environment, other application programs, database structure which house the agency data (DB/2 and ADABAS), and the communications network. The technical specialists filling this position must be able to plan, evaluates, installs, and implements mainframe software, databases (ADABAS DB2), and security solutions that resides on the mainframe platform while also doing complex installation and maintenance activities to mainframe operating system software. All of the core networking and CICS systems utilized by the DES are maintained and managed by this assigned unit. This unit also monitors and diagnoses problems related to these software components and evaluates system performance. This position works in close cooperation and coordination with other technical units in DTS to ensure responsive end-user performance. In addition, this position is a participant in the networking design group supporting all data communications activities conducted by the department which includes other technical units within DTS. The unit also provides direct support for internal network components that are out of scope to the States telecommunications provider. See KSAs below. This assignment requires that the successful candidate will work at 1720 West Madison, Phoenix and a work schedule can be determined upon selection. Usual work hours are 8:00 am through 5:00 pm , Monday through Friday, except holidays. There may be some after hours duty to resolve production issues but most work weeks will be limited to 40 hours. *REQUIRED KNOWLEDGE, SKILLS AND ABILITIES (KSAs):* *KNOWLEDGE of*: Large mainframe computer operating systems communications networks, Systems applications that run on large mainframe computer, CICS software and related products, utility software operation, SNA, TCP/IP network protocols, network design, analysis and troubleshooting tools, Network hardware, network architecture used by DES including MPLS, VPN structures and how to establish and maintain them, FTP and other TCP/IP utilities on the mainframe, industry and state standards for personnel management. Extensive knowledge and understanding of z/OS operation and architecture, Mainframe software to include ADABAS, Nature, Natural security, DB2, SQL, Platinum, CICS, Cobol II, SPUFI, Predict, Optimizer, Con-Nect, Construct ADAPREP, Natural with DB2, Rexx. Knowledge of z/OS performance data and reporting and interpretation If you are qualified, available, interested, planning to make a change, *or know of a colleague* who might have the required qualifications and interest, please email me at ken.ek...@bakerit.com /mc/compose?to=ken.ek...@bakerit.com or call me at (612) 723-4994. *Email may be the fastest way to correspond initially, especially since I will need your resume for submittal JUST for this requirement
Re: static const arrays in C
On Fri, 24 Aug 2012 10:13:21 -0400, Thomas David Rivers wrote: As Gil mentioned - this is only really true for static data... extern data can't be trusted because the user might have put the 'const' keyword in one declaration, and left it off in another... which would mean that the extern reference might be a RENT one, while, say, the definition was non-RENT. ANSI seems to allow this as long as no translation unit modifies the data. Otherwise the effect is undefined. So a conforming implementation is free to put the object in write-protected storage. S0C4 fits within the notion of undefined. In your situation - where you are declaring a large array of doubles - putting the data in non-RENT memory can be a big win. non-RENT? ITYM RENT so it doesn't get copied. This is only supported by the assumption that if the programmer says const - he really means it... that's the point of the ROCONST option in the IBM compiler. So, you can say oh - I guess the programmer didn't _really_ mean it. I would hate to have to support such misbehavior. But, I suppose, The customer is always right. This is reminiscent of the OS's not loading modules marked REFR into write-protected storage because so many programmers didn't _really_ mean it I think that's been fixed. Installation option? REFRPROT comes to mind. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: execs or scripts
re: http://www.garlic.com/~lynn/2012l.html#8 execs or scripts http://www.garlic.com/~lynn/2012l.html#9 execs or scripts http://www.garlic.com/~lynn/2012l.html#15 execs or scripts http://www.garlic.com/~lynn/2012l.html#20 execs or scripts other trivia ... vm/cms SE on financial services accounts in LA branch office, did re-implementation of script for trs-80, past reference: http://www.garlic.com/~lynn/2004l.html#74 Specifying all biz rules in relational data http://www.garlic.com/~lynn/2011n.html#58 Geek t-shirts -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: execs or scripts
Relevance? On Fri, Aug 24, 2012 at 11:07 AM, Anne Lynn Wheeler l...@garlic.comwrote: re: http://www.garlic.com/~lynn/2012l.html#8 execs or scripts http://www.garlic.com/~lynn/2012l.html#9 execs or scripts http://www.garlic.com/~lynn/2012l.html#15 execs or scripts http://www.garlic.com/~lynn/2012l.html#20 execs or scripts other trivia ... vm/cms SE on financial services accounts in LA branch office, did re-implementation of script for trs-80, past reference: http://www.garlic.com/~lynn/2004l.html#74 Specifying all biz rules in relational data http://www.garlic.com/~lynn/2011n.html#58 Geek t-shirts -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: execs or scripts
zedgarhoo...@gmail.com (zMan) writes: Relevance? my bad, thread in comp.lang.rexx that went to wrong place -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: execs or scripts
Your bad it may be, but I cannot refrain from noting that, while I too prefer 'script' to 'exec', even 'exec' is better than talking/writing about 'a REXX' or REXXs'; and this subliterate usage appears to be spreading: we have far too much of it on IBM-MAIN. --jg On 8/24/12, Anne Lynn Wheeler l...@garlic.com wrote: zedgarhoo...@gmail.com (zMan) writes: Relevance? my bad, thread in comp.lang.rexx that went to wrong place -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: execs or scripts
I prefer exec myself, but I believe a true exec should have been written in EXEC or EXEC 2 language, not Rexx. I find a Rexx to be awkward, but I'm not convinced that it's incorrect. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: execs or scripts
Bob, I'm not sure I agree. My problem is that your view sanctions, implicltly encourages, usages like 'an Assembler' for an assembly-language program or 'a COBOL' for a COBOL program. The distinction between the entity, routine or table, and the language in which it is written is valuable, worth trying to preserve. --jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: execs or scripts
On Fri, Aug 24, 2012 at 11:54 AM, Bob Shannon bshan...@rocketsoftware.com wrote: I prefer exec myself, but I believe a true exec should have been written in EXEC or EXEC 2 language, not Rexx. I find a Rexx to be awkward, but I'm not convinced that it's incorrect. Right. A Rexx is actually analogous to An EXEC or A CLIST, even though we VMers find it grating. But arguably A Rexx EXEC is (as Bob suggests) the anomaly. I still likely won't start calling it A Rexx until well after they put me in the Old Sysprogs Home... (You had 16M? We had 256K! And we LOVED it! Only cost a nickel...) -- ...phsiii Phil Smith III p...@voltage.commailto:p...@voltage.com Voltage Security, Inc. www.voltage.comhttp://www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OpenSSH Marketing requirement MR0822125916
Cross Posted to IBM-Main and MVS-OE While at Share I worked to have an MR for OpenSSH to recognize classic MVS datasets opened. The requirement has been recognized. If your shop would also be interested in the ability it would be useful to have your account added to the interested parties list for the requirement. See below: User Group Number - MR0822125916 Document Status - Recognized Title - OpenSSH utilities need ability to access MVS data sets IBM agrees with the request and a solution appears to be a desirable objective. A solution however may not presently appear feasible or implementable. No IBM commitment is made or implied as to the eventual delivery of an acceptable solution. Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: execs or scripts
I usually say script because of use of shell script in UNIX. For REXX, I often say REXX program. What I really hate is REXX clist. Which is it, REXX or CLIST? On VM, I guess REXX exec could also give rise to REXX or EXEC (EXEC being conceptually similar to CLIST in this context). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, August 24, 2012 10:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: execs or scripts Your bad it may be, but I cannot refrain from noting that, while I too prefer 'script' to 'exec', even 'exec' is better than talking/writing about 'a REXX' or REXXs'; and this subliterate usage appears to be spreading: we have far too much of it on IBM-MAIN. --jg On 8/24/12, Anne Lynn Wheeler l...@garlic.com wrote: zedgarhoo...@gmail.com (zMan) writes: Relevance? my bad, thread in comp.lang.rexx that went to wrong place -- virtualization experience starting Jan1968, online at home since Mar1970 - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM- MAIN -- 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: OpenSSH Marketing requirement MR0822125916
Or, if you need it now, get (free as in beer, zero cost) Dovetailed Technologies' sftp add-on. It not only allows accessing z/OS data sets (upload and download, binary or ascii), but can be used to submit jobs and retrieve sysout. Oh, and z/OS UNIX files too, of course. http://dovetail.com/products/sftp.html quote Co:Z SFTP is a port of OpenSSH SFTP for z/OS which adds support for z/OS datasets, catalogs, spool files, SMF, etc. This product is designed to work with secure SSH connections provided by IBM Ported Tools for z/OS - OpenSSH. The rich set of z/OS features in Co:Z SFTP are implemented in such a way as to be completely accessible from OpenSSH or standard-compliant SFTP products on other platforms. Using Co:Z SFTP-server, systems with OpenSSH or another sftp compatible client may transfer files directly to z/OS datasets and control all aspects of dataset allocation, formats, and codepage conversion. Co:Z SFTP retains compatibility with OpenSSH sftp, supporting the binary transfer of z/OS UNIX files, but also supports codepage and line terminator conversion. Using Co:Z SFTP client, z/OS datasets and POSIX files can be transferred. The client may be used interactively or from a z/OS batch job (typically from within a Co:Z Batch job step). /quote -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Friday, August 24, 2012 12:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: OpenSSH Marketing requirement MR0822125916 Cross Posted to IBM-Main and MVS-OE While at Share I worked to have an MR for OpenSSH to recognize classic MVS datasets opened. The requirement has been recognized. If your shop would also be interested in the ability it would be useful to have your account added to the interested parties list for the requirement. See below: User Group Number - MR0822125916 Document Status - Recognized Title - OpenSSH utilities need ability to access MVS data sets IBM agrees with the request and a solution appears to be a desirable objective. A solution however may not presently appear feasible or implementable. No IBM commitment is made or implied as to the eventual delivery of an acceptable solution. Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. Email Firewall made the following annotations. --- --- Warning: All e-mail sent to this address will be received by the corporate e- mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. === === -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to retain volumes by days when VOLUME VRS is used in DFSMSrmm
Massaki-san said : But I could not find out the description or the explanation regarding to type of retention for the COUNT in VOLUME VRS. I have checked R6, R10, R13 RMM GR manuals. I you point out where the description in the manual, I really appreciate it. A: It is kind-of in the GR under ADDVRS COUNT explanation. Use COUNT(number_of_days) to request that DFSMSrmm retain all cycles or copies of a data set, bor a volume for the number of days you require. /b Use COUNT(number_of_volumes) to request that DFSMSrmm retain bthe number of volumes you want. /b Down with STORENUMBER operand it is much clearer Mike Wood -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: execs or scripts
Phil, Worked VM since SP1, they were always execs to me. Scripts makes me think Nix, unix . Scott ford www.identityforge.com On Aug 24, 2012, at 12:18 PM, Phil Smith p...@voltage.com wrote: On Fri, Aug 24, 2012 at 11:54 AM, Bob Shannon bshan...@rocketsoftware.com wrote: I prefer exec myself, but I believe a true exec should have been written in EXEC or EXEC 2 language, not Rexx. I find a Rexx to be awkward, but I'm not convinced that it's incorrect. Right. A Rexx is actually analogous to An EXEC or A CLIST, even though we VMers find it grating. But arguably A Rexx EXEC is (as Bob suggests) the anomaly. I still likely won't start calling it A Rexx until well after they put me in the Old Sysprogs Home... (You had 16M? We had 256K! And we LOVED it! Only cost a nickel...) -- ...phsiii Phil Smith III p...@voltage.commailto:p...@voltage.com Voltage Security, Inc. www.voltage.comhttp://www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- 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: OS/390 CD collection free to a good home
Precisely why I posted. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Elardus Engelbrecht :: Sent: Friday, August 24, 2012 1:53 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: OS/390 CD collection free to a good home :: :: retired mainframer wrote: :: :: I have the complete 9 CD Online Library OS/390 Collection, dated :: September 1998, SK2T-6700-10. If anyone has any use for it, I will :: gladly mail them the CDs and the IBM binder. I will wait a week or so :: for off-line responses before contributing them to the city land-fill. :: :: Donate it to a computer museum. There are lurkers on IBM-MAIN who are :: representing them. Perhaps they will contact you off-list. :: :: Sorry, I don't have any links of them for now... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Documenting SMS environment ACS routines.
BTDT. But at least the guy who follows you will have something better than what you were left with. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of McKown, John :: Sent: Friday, August 24, 2012 5:41 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Documenting SMS environment ACS routines. :: :: Thanks for that LISTPRT pointer. I used it to create data sets with that :: data. That will make it easier to include in my documentation. Of course, :: doing so will almost guarantee that the documentation will become :: obsolete. We're not too good on keeping our documentation up to date. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OS/390 CD collection free to a good home
I'm your Huckleberry. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Thursday, August 23, 2012 5:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: OS/390 CD collection free to a good home I have the complete 9 CD Online Library OS/390 Collection, dated September 1998, SK2T-6700-10. If anyone has any use for it, I will gladly mail them the CDs and the IBM binder. I will wait a week or so for off-line responses before contributing them to the city land-fill. -- 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: X86 server
Just for my 2 cents worth, ran P390s in one environment attached to two T1s. Attached to them we're 3800 laser printers and some 3274s we couldnt replace. The mainframes were an hour plus away in NJ, and our printed output queued up to the P390s. Everything worked like a champ. I am now on Z/Pdt z/os1.12 on a intel i7', everything s good, but are also only doing development. Scott ford www.identityforge.com On Aug 23, 2012, at 12:11 PM, Anne Lynn Wheeler l...@garlic.com wrote: john.mck...@healthmarkets.com (McKown, John) writes: X64 hardware, as much as it has improved, is still not as reliable or have the I/O capacity of the z hardware. E.g.: We had a TCM fail once. A spare picked up the work, automatically restarting the instruction stream, with no outage of any sort and no software involvement. X86, from what I'm told, would at least require the OS to do the equivalent of a checkpoint restart. Also had an OSA fail. The other OSA did an ARP takeover and no IP sessions were lost. TCPIP was informed, but all it did was put out a message and not start any new sessions on the failing OSA. Our open people called me a liar when I told them that. big cloud operators do hundreds of thousands of blades in megadatacenter with lots of failure/recovery infrastructure to handle individual blade failures (usually with lots of power, telco, provisioning provisioning). Gray had been studying mix of failures issues (both at IBM and later at Tandem) and by '84 published report that hardware failures had become minority of failure modes (hardware reliability had increased so other kinds of failures were starting to dominating). scan of '84 presentation http://www.garlic.com/~lynn/grayft84.pdf several of the big cloud operators have published detailed studies of different component availability as part of building their own blades ... given optimal service life per dollar. Cluster take-over were increasingly being used to mask all kinds of outages ... even able to handle geographic operations and handling disasters taking out whole datacenter. when we were doing ha/cmp ... we did a lot of failure mode study ... and part of our marketing was against hardware fault-tolerant systems. We showed availability of ha/cmp clusters was higher than the fault-tolerant systems. In competitive situation involving 1-800 number server (i.e. maps 1-800 number to real number) ... it required five-nines availability. hardware fault-tolerant system still required scheduled system outage to do software upgrade ... which would blow several decades of downtime budget. With cluster operation, we showed at least as good hardware availability (with redundant systems) along with capability of doing rolling software upgrades with no system outage. the hardware fault tolerant vendor eventually came back with suggestion that they could come out with redundant, cluster system operation ... to handle the software upgrade issue. However, given reliability of the underlying hardware operating in redundant, cluster system mode ... there was no longer any justification for hardware fault tolerance. part of ha/cmp was ip-address take-over ... which according to all the standards should time-out mac/ip-address in arp caches. at the time, most vendors were using BSD 4.3 tahoe or reno software for their tcp/ip stacks. In 1989, we found a bug in the BSD4.3 tahoe/reno IP/ARP lookup software. The ARP cache management was correctly timing out the ARP cache entries (so if there was ip-address take-over, it would discover the new MAC mapping). However, the BSD4.3 IP code had a performance optimization where it saved the last ip/mac lookup results ... which would only get reset if the client communicated with a different ip-address (otherwise that saved ip/mac mapping would exist forever). Since the bug existed in nearly every vendors implementation (all using same BSD4.3 tahoe/reno software), we had to come up with a work-around for the saved ip/mac bug. Any time there was ip-address take-over, we would quickly saturate the local LAN with dummy traffic from a different ip-address ... forcing all the machines on that LAN to perform a real ARP cache lookup (resetting the saved value). Then the next activity from the taken-over ip-address would force the clients to do a real ARP cache lookup. misc. past posts mentioning ha/cmp http://www.garlic.com/~lynn/subtopic.html#hacmp -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Documenting SMS environment ACS routines.
John, I wished I could help out. I have to write manuals for our products, writing isn't one of my finer points. I was thinking about creating a file to feed Visio to do doc work like what your referring to Scott ford www.identityforge.com On Aug 24, 2012, at 8:41 AM, McKown, John john.mck...@healthmarkets.com wrote: Thanks for that LISTPRT pointer. I used it to create data sets with that data. That will make it easier to include in my documentation. Of course, doing so will almost guarantee that the documentation will become obsolete. We're not too good on keeping our documentation up to date. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Thursday, August 23, 2012 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Documenting SMS environment ACS routines. ISMF options 3, 4, 5, and 6 have the LSTPRT command to document the properties of every data class, management class, storage class, and storage group. Option 7 can identify from where each of the ACS routines was compiled so you can find the source if it still exists. It can also identify any test cases your storage admin used when he developed the system. The D SMS system command can display the status of each storage group and the volumes in that group. Unfortunately, none of this will give you the philosophy or rationale of why things are this way. You will have to infer that based on your understanding of your business environment and anything you know about the admin himself. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On :: Behalf Of McKown, John :: Sent: Thursday, August 23, 2012 10:35 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Documenting SMS environment ACS routines. :: :: We have a rather fragile SMS environment at present. It has basically :: grown ad hoc over the course of almost 2 decades. I really need to :: document it very well. Once documented, I would like to use that in :: order to reengineer the environment. Any pointers would be greatly :: appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: X86 server
scott_j_f...@yahoo.com (Scott Ford) writes: Just for my 2 cents worth, ran P390s in one environment attached to two T1s. Attached to them we're 3800 laser printers and some 3274s we couldnt replace. The mainframes were an hour plus away in NJ, and our printed output queued up to the P390s. Everything worked like a champ. I am now on Z/Pdt z/os1.12 on a intel i7', everything s good, but are also only doing development. Scott ford www.identityforge.com re: http://www.garlic.com/~lynn/2012l.html#16 X86 server http://www.garlic.com/~lynn/2012l.html#18 X86 server http://www.garlic.com/~lynn/2012l.html#19 X86 server http://www.garlic.com/~lynn/2012l.html#20 X86 server 1980 STL is bursting at the seams and they are moving 300 people from IMS group to off-site bldg. the group tries remote 3270 support and find it intolerable. I get con'ed into writing HYPERChannel support for use as channel extender ... allowing them to put local channel-attached 3270 controllers at the remote site. Runs over T1 channel on the *campus* collins digital radio T3 microwave. They don't notice any change from cms local 3270 controllers in STL (maintaining their subsecond response ... back when mvs/tso people were claiming noody needed subsecond response). System thruput actually improves ... issue is the HYPERChannel A220s sitting on real channel have significantly lower channel busy (for the same operation) than 3270 controllers ... total system throughput improves 10-15% (the 3270 controller channel busy is masked at the remote site). I try to get approval to release the software to customers ... which a group in POK manages to block. That group was playing with some fiber stuff (that eventually gets out as ESCON), and they are afraid if my HYPERChannel support is released to customers ... it would interfer with someday being able to get their fiber stuff out. As a result NSC has to re-do my implementation from scratch. Roll forward several years, the 3090 product administrator tracks me down. the 3090 channels were designed to have 3-5 channel checks annually aggregate across the whole customer base. the industry service that collects erep data shows that there have been an aggregate of 20 channel checks the first year. Turns out they are at customers running 3800 over HYERPChannel channel extender. In my original implementation ... if I had an unrecoverable transmission error ... I would simulate channel check in the CSW ... for the host software to go through its retry operation ... and the NSC faithfully reproduced that in their implementation. After some amount of toiling through error recovery code ... i determined that simulating IFCC would have effectively the same result as channel check and got NSC to update their implementation. as an aside, long ago and far away somebody in Boulder does build a hardware channel emulator for ibm/pc which is used for 3800 testing. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What size memory object backs an IARCP64
Look at EXPAND=NO|YES --jg On 8/24/12, Dave Day david...@consolidated.net wrote: On CPOOL BUILD, one specifies PCELLCT and SCELLCT to tell z/OS how to build the pool. There doesn't appear to be any equivalent for IARCP64 REQUEST=BUILD. No way to communicate to z/OS how many you think you will need? I must be missing something here. --Dave -- 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: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10
Love this product * MVS/QuickRef 7.5 * (c) If they object to my expression of affection I will never cut/paste from them again. Fair use guys? # Data Base Vendor ProductPreferred Release _ 1 M IBM Z/OS SYSTEM MSGS V1R10 Have _ IBM Z/OS SYSTEM MSGS V1R1 M through _ IBM Z/OS SYSTEM MSGS V1R13 M .01.IEC161I 037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,, --- V=IBM P=Z/OS SYSTEM MSGS R=V1R10 I=IEC161I D=M - ++ ¦ RETURN CODE 108 ¦ ¦ ¦ ¦ Explanation: An incorrect field name was found in the field parameter ¦ ¦ list (CTGFL). The field name passed by AMS does not exist in the ¦ ¦ catalog management dictionary. ¦ ++ Reason Code Description 0 Programmer Response: The message indicates that the caller's AMS release level or maintenance level is different from the CATALOG level that is being called. Ensure that IDCAMS and CATALOG are at the same level. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What size memory object backs an IARCP64
IARCP64 can allocate pools comprised of cells ranging in size from 1 byte to 512 Kib. Its design is different from that of the analogous AMODE(31) facilities and in some ways better. As usual for macros of this class, usable only in assembly language and PL/X, the only really good, usually very current documentation is in the prolog of the macro itself. Read it. Then ask questions. --jg On 8/24/12, Dave Day david...@consolidated.net wrote: The 1.12 manual I looked at has the following. Doesn't say a bleeping thing about the original size. I wish to move some pools above the bar, and have some idea of how many I will need, in each. I would like to be able to indicate that at the beginning, but it doesn't appear to be possible. --Dave ,EXPAND=YES ,EXPAND=NO When REQUEST=GET is specified, a required parameter that indicates whether to attempt expanding the pool if there is no available cell. ,EXPAND=YES This parameter tries expanding. ,EXPAND=NO This parameter does not try expanding. ,TRACE= On 8/24/2012 4:04 PM, John Gilmore wrote: Look at EXPAND=NO|YES --jg -- 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: X86 server
What does this have to do with this thread??? On Fri, Aug 24, 2012 at 4:13 PM, Anne Lynn Wheeler l...@garlic.comwrote: scott_j_f...@yahoo.com (Scott Ford) writes: Just for my 2 cents worth, ran P390s in one environment attached to two T1s. Attached to them we're 3800 laser printers and some 3274s we couldnt replace. The mainframes were an hour plus away in NJ, and our printed output queued up to the P390s. Everything worked like a champ. I am now on Z/Pdt z/os1.12 on a intel i7', everything s good, but are also only doing development. Scott ford www.identityforge.com re: http://www.garlic.com/~lynn/2012l.html#16 X86 server http://www.garlic.com/~lynn/2012l.html#18 X86 server http://www.garlic.com/~lynn/2012l.html#19 X86 server http://www.garlic.com/~lynn/2012l.html#20 X86 server 1980 STL is bursting at the seams and they are moving 300 people from IMS group to off-site bldg. the group tries remote 3270 support and find it intolerable. I get con'ed into writing HYPERChannel support for use as channel extender ... allowing them to put local channel-attached 3270 controllers at the remote site. Runs over T1 channel on the *campus* collins digital radio T3 microwave. They don't notice any change from cms local 3270 controllers in STL (maintaining their subsecond response ... back when mvs/tso people were claiming noody needed subsecond response). System thruput actually improves ... issue is the HYPERChannel A220s sitting on real channel have significantly lower channel busy (for the same operation) than 3270 controllers ... total system throughput improves 10-15% (the 3270 controller channel busy is masked at the remote site). I try to get approval to release the software to customers ... which a group in POK manages to block. That group was playing with some fiber stuff (that eventually gets out as ESCON), and they are afraid if my HYPERChannel support is released to customers ... it would interfer with someday being able to get their fiber stuff out. As a result NSC has to re-do my implementation from scratch. Roll forward several years, the 3090 product administrator tracks me down. the 3090 channels were designed to have 3-5 channel checks annually aggregate across the whole customer base. the industry service that collects erep data shows that there have been an aggregate of 20 channel checks the first year. Turns out they are at customers running 3800 over HYERPChannel channel extender. In my original implementation ... if I had an unrecoverable transmission error ... I would simulate channel check in the CSW ... for the host software to go through its retry operation ... and the NSC faithfully reproduced that in their implementation. After some amount of toiling through error recovery code ... i determined that simulating IFCC would have effectively the same result as channel check and got NSC to update their implementation. as an aside, long ago and far away somebody in Boulder does build a hardware channel emulator for ibm/pc which is used for 3800 testing. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: execs or scripts
John, Maybe the usage of execs or rexx in writing or speaking might be based on whether you learned iron VM or z/OS. I learned my on VM. So I can only give you my perspective. Scott ford www.identityforge.com On Aug 24, 2012, at 12:15 PM, John Gilmore jwgli...@gmail.com wrote: Bob, I'm not sure I agree. My problem is that your view sanctions, implicltly encourages, usages like 'an Assembler' for an assembly-language program or 'a COBOL' for a COBOL program. The distinction between the entity, routine or table, and the language in which it is written is valuable, worth trying to preserve. --jg -- 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: ISPF Panel and LPAR name
Tut tut. Not a mention of 'using a search engine' in my quoted reply. In fact, I use them regularly. You seem confused. Meanwhile, Germany's economy is thriving while Greece's one is on its knees. The former relies on science/engineering, the latter on art/entertainment (and on hanging dogs from trees, dousing them in parrafin oil and setting them on fire alive for 'entertainment' purposes). Du kannst mich mal am Arsch lecken. Ta ta Shmuel Metz (Seymour J.) wrote: In 50359f17.2080...@bcs.org.uk, on 08/23/2012 at 04:10 AM, CM Poncelet ponce...@bcs.org.uk said: Well ... art/entertainment v. science/engineering as in Aesop's fable about the Cicala and the Ant. Industry makes its own bread: it does not sing all summer and expect bread when winter arrives. Nonsense. Using a search engine is not remotely analogous to singing all summer. If anything, refusing to use a search engine is a manifestation of the NIH syndrome. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: X86 server
On Thu, 23 Aug 2012 22:13:49 -0400, Anne Lynn Wheeler wrote: ... max configured z196 with 80 processors is rated for 50BIPS and goes for $28M (about $560,000/BIPS) ... ibm has base price of $1815 for e5-2600 blade ... which have ratings at 527BIPS (about $3.44/BIPS), ... A factor of 160,000. The mind boggles. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: execs or scripts
From IBM's terminology website: Restructured Extended Executor The i5/OS implementation of the Systems Application Architecture Procedures Language. REXX is a programming language that is supported by an interpreter provided as part of the i5/OS licensed program. A general-purpose, high-level programming language, particularly suitable for EXEC procedures or programs for personal computing. They consider REXX a language Scott ford www.identityforge.com On Aug 24, 2012, at 1:11 PM, McKown, John john.mck...@healthmarkets.com wrote: I usually say script because of use of shell script in UNIX. For REXX, I often say REXX program. What I really hate is REXX clist. Which is it, REXX or CLIST? On VM, I guess REXX exec could also give rise to REXX or EXEC (EXEC being conceptually similar to CLIST in this context). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, August 24, 2012 10:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: execs or scripts Your bad it may be, but I cannot refrain from noting that, while I too prefer 'script' to 'exec', even 'exec' is better than talking/writing about 'a REXX' or REXXs'; and this subliterate usage appears to be spreading: we have far too much of it on IBM-MAIN. --jg On 8/24/12, Anne Lynn Wheeler l...@garlic.com wrote: zedgarhoo...@gmail.com (zMan) writes: Relevance? my bad, thread in comp.lang.rexx that went to wrong place -- virtualization experience starting Jan1968, online at home since Mar1970 - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM- MAIN -- 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
