Re: Command program from the cbt

Which version of command are you using? There were two versions taht used to be on CBT, one that I had updated a bit but was actually Food Lion's code and another one that we stopped putting there (same name) after 2005 or so that we completely re-wrote and added 36 special commands and IF/THEN/EL

Fw: COBOL: Getting calling modules name etc. - LE services ?

I think that the facility that you are looking for would be met when/if IBM actually provides the enhancement in the existing SHARE requirement: SSLNGC0313587 New LE Callable Service to get (various) Program Names Described as: "A new LE callable service (with capabilities well beyond CEE3G

Re: S222 abends and Reason Codes

-- I can think of no case where it is accepted or supported for non-IBM code to issue an IBM-documented system abend code. And that certainly includes 222 which has many ramifications that go with its being a "cancel'. As we all kno

Re: COBOL: Getting calling modules name etc. - LE services ?

Hi Look at the Layout Entry of Language Environment-Conforming Routines – Standard: http://publib.boulder.ibm.com/infocenter/zos/v1r10/topic/com.ibm.zos.r10.ceev100/rtnlyout.htm?resultof=%22%70%70%61%31%22%20 or: http://publibz.boulder.ibm.com/epubs/pdf/ceev1190.pdf Chapter 1. Common Interfa

Re: S222 abends and Reason Codes

In the old COBOL days, I would call XPECT806, which didn't exist, and got what I asked for Peter Relson wrote: I can think of no case where it is accepted or supported for non-IBM code to issue an IBM-documented system abend code. And that certainly includes 222 which has many ramification

Re: S222 abends and Reason Codes

I can think of no case where it is accepted or supported for non-IBM code to issue an IBM-documented system abend code. And that certainly includes 222 which has many ramifications that go with its being a "cancel'. As we all know, the "official" S222 has no reason codes. Peter Relson z/OS Core

Re: SV: COBOL: Getting calling modules name etc. - LE services ?

Thomas Berg wrote: Thanks! When looking in LE Vendor Interfaces it seems that it could be possible. But a working example/scenario would be very helpful for me as I'm close at loss of how to start. E g how do I get the address of the DSA in a COBOL pgm to beging with. Etc. Regards, Th

SV: COBOL: Getting calling modules name etc. - LE services ?

Thanks! When looking in LE Vendor Interfaces it seems that it could be possible. But a working example/scenario would be very helpful for me as I'm close at loss of how to start. E g how do I get the address of the DSA in a COBOL pgm to beging with. Etc. Regards, Thomas Berg ___

Re: SMPE usermod sample

On Thu, 2 Jul 2009 20:47:47 -0400, Jeffery Swagger wrote: >Yes, but this strikes me as incomplete. > >I did try an APPLY CHECK of the proposed USERMOD (minus the JCLIN) and >it appeared to produce the desired result. >In that a ++EXEC element would be created (target library SISPEXEC) with >an AL

Re: ERASEDATA - DASD disposal

On Fri, 3 Jul 2009 07:24:02 -0400, Klein, Kenneth wrote: > Even more insidious are the methods of reading how strongly the >magnetized bit is positive or negative. If the bit is on, but not as >strongly as others, it might have been off before getting flipped. If >very strongly on it might have be

Re: COBOL: Getting calling modules name etc. - LE services ?

Hi Maybe in the Vendor Interfaces CEETBCK etc (Never tried from COBOL) Thomas Berg wrote: Hi, Does anyone know a way to get the actual calling modules name in a COBOL program ? Also other details about the calling module would be interesting. I looked through LE Programming Reference for c

Re: Where does z/unix store each lpar's hostname?

Use "sysvar LPAR" , you will get LPAR name Klein, Kenneth wrote: I thought it would be in /etc... Ken Klein Sr. Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@b

Re: Converting CPU Time to MIPS

It may not be relevant to this particular application, but it is often important to look at the big picture. Years ago, a client I was supporting had a batch job that ran extremely long. Analysis revealed that most of the time was spent in a calculation of the penalty for early withdrawal that

Where does z/unix store each lpar's hostname?

I thought it would be in /etc... Ken Klein Sr. Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the arch

Re: ERASEDATA - DASD disposal

Even more insidious are the methods of reading how strongly the magnetized bit is positive or negative. If the bit is on, but not as strongly as others, it might have been off before getting flipped. If very strongly on it might have been reinforced when the 1 bit was written to it. It would take

COBOL: Getting calling modules name etc. - LE services ?

Hi, Does anyone know a way to get the actual calling modules name in a COBOL program ? Also other details about the calling module would be interesting. I looked through LE Programming Reference for callable services buth didn't find any (obvious) such function. Any hints ? Regards, Thomas B

Re: How to convince not to over initiate?

>You could have used SYSAFF I did. I just didn't do it right :-( >you also could have SCHENV defined and activated on the LPAR you needed >to run on. But that would require *planning* and *foresight*! :-( When a job doesn't run where it is submitted (we *do* set sysaff on a $Tintrdr command dur

Andy Pesce is out of the office.

I will be out of the office starting 07/02/2009 and will not return until 07/13/2009. I will respond to your message when I return. If you need immediate assistance contact Scott Taylor or Doug Mallory. -- For IBM-MAIN subscrib

AUTO: James Obrizok is out of the office (returning 07/06/2009)

I am out of the office until 07/06/2009. If you require immediate assistance, please contact my backup Fernando Vega on 1-404-238-4580 or Jon Regitsky on 1-404-238-3134. Thank you. Note: This is an automated response to your message "IBM-MAIN Digest - 1 Jul 2009 to 2 Jul 2009 (#2009-183)" sent