Re: Reversing the Catalog Definition entries

[Walter Marguccio]

From: Jake anderson 

To: IBM-MAIN@bama.ua.edu 

> Are there any sample JCLs which would perform the above stuff at once for
> all 214 datasets.

the best method I can think of is Mark Zelden's REXX INDIRECR:


http://www.mzelden.com/mvsfiles/indirecr.txt

which will provide the IDCAMS control statements to accomplish what
you want to do.


Walter Marguccio

z/OS Systems Programmer
BELENUS LOB Informatic GmbH
Munich - Germany

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

Re: GO TO "cobol"

[Ed Gould]

Loyd:

Fort Wauchooka (sp??) rings a bell somewhere in my cob  ridden  
memory. But I also now remember Ft Ben Harrison (now). I remember the  
guys talking about the desert and thats about all.


Ed

On Apr 17, 2012, at 7:17 AM, Lloyd Fuller wrote:

In 1969, and until sometime in the 1970s or later, the Army  
programming school

was at Fort Benjamin Harrison in Indiana.


Graduated in March 1969 as a Staff Sergeant converted to a SP6.   
Programming

since then.

lLOYD



- Original Message 
From: Ed Gould 
To: IBM-MAIN@bama.ua.edu
Sent: Tue, April 17, 2012 12:16:33 AM
Subject: Re: GO TO "cobol"

On Apr 16, 2012, at 8:34 AM, McKown, John wrote:

SNIP-
Also remember that COBOL, at least originally, was supposed to be  
very
English-like and so usable by people at the Army PFC level of  
training.


--John McKown
Systems Engineer IV
IT


Hmmm... I was in the Army and we got PFC's from the programming  
school (AZ? its
been 40 years so forgive me). We had two groups, one COBOL (batch  
processing)
and one ASM group (essentially sysprogs). The ASM group was by far  
the best IMO.
I was on call quite often and had to "fix" the cobol programs that  
went boom in
the middle of the night. The COBOL people were semi useless in  
debugging and
when I looked at the code they had produced (except for a few  
people) it was
hopeless to understand. I spent more time trying to figure out the  
logic and
compare what I was seeing in the dump. 1/3 the time I helped the  
programmer
figure out where his problem was and supplying answers to his  
questions on what

was in this field or that field.
What was interesting was that as the guys (no female programmers so  
don't call
me sexist blame the Army not me) as they became more experienced  
the code became
easier to follow. As they became became better programmers there  
were less logic
problems. Now having said that most of the programs were  smallish  
and only a
few were considered large so the smallish programs there was no  
excuse for logic
issues or mangled code. My memory is foggy here as to goto's but I  
think the
"rule" no standards if memory serves me that goto's were to be  
minimized as a

result flow was easier to follow and frankly debugging was easier.

Ed

ps: We had one person who at the time he was drafted was working  
for IBM and he
privately told me about some OS enhancements that when I first  
heard I couldn't
wrap my head around as virtual (at least that I had never heard of)  
was a
nightmare that I couldn't wrap my head around. After I got out of  
the Army (2
years) IBM announced Virtual and I was able to ask some semi  
intelligent

questions as my "preview" and the questions helped jump start by job.

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

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


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

Re: Reversing the Catalog Definition entries

[Mike Schwab]

On Tue, Apr 17, 2012 at 10:15 PM, Jake anderson
 wrote:
> Hello ,
>
> "If you bring the datasets up in ISPF 3.4, just type a U in front of the
> DSN(s) and when that completes, type a C"
>
> Are there any sample JCLs which would perform the above stuff at once for
> all 214 datasets.
>
> Jake
>

//jobname JOB acct, etc
//stepname EXEC PGM=IEFBR14
//UDSN1  DD DISP=(OLD,UNCATLG).DSN=hlq1.dsn1
//CDSN1 DD UNIT=3390,VOL=SER=vv,DISP=(OLD,CATLG),DSN=hlq1.dsn1

Just typed, not tested.  Cut and paste from 3.4 listing, or in 3.4 use
P command and exit to save the list and use the next number.

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

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[John McKown]

Guess I am spoiled by the assembler (as command) and C/C++ compiler's
support of both UNIX paths and z/OS PDS[E]s.

I have a, to me, clumsy way to get around it. I started up the NFS
server and exported the high level qualifier that had the PDS[E]s that I
needed, then did a MOUNT onto a z/OS UNIX subdirectory. Clumsy, but it
does work.

I may write my own version of the cob2 command which does what _I_ want.
Should be fairly easy. Just set up the allocations as needed using
DYNALLOC, then use BPX1ATM UNIX routine to ATTACH the IGYCRCTL program.

The main problem that I have with my UNIX programs is that I can only
use HLASM (no C compiler license). And I have not figured out how to
handle UNIX signals. So the c to abort a command doesn't work.

On Tue, 2012-04-17 at 15:04 -0700, Tom Ross wrote:
> >On 4/16/2012 3:26 PM, McKown, John wrote:

> It clearly says only directories and paths, but I suppose a confirmation
> that datasets are not supported would be nice.  I will try to get that into
> the next version of the Programming Guide.  If anyone has a better suggestion
> for where this confirmation would go, let me know!
> 
> Cheers,
> TomR  >> COBOL is the Language of the Future! <<

-- 
John McKown
Maranatha! <><

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[John McKown]

I do use a UNIX subdirectory on my SYSEXEC concatenation. But, as you
said, it cannot be first. So I have an empty PDS with FB/80 as the first
DSN in the concatenation. A clumsy work around, but at least it works
for me.

On Tue, 2012-04-17 at 17:27 -0500, Paul Gilmartin wrote:
> On Tue, 17 Apr 2012 13:07:18 -0600, Steve Comstock wrote:
> 
> >On 4/17/2012 12:53 PM, McKown, John wrote:
> >> As the OP, I thought I'm mention that I finally got the z/OS NFS server to
> >allow me to mount a high-level onto a z/OS UNIX subdirectory on the same 
> >system.
> >
> >Clever and resourceful. But certainly just a workaround for
> >the situation: you would like the compilers to be able to
> >use MVS data sets directly for SYSLIB (and other DD names).
> >
> More than "just a workaround".  It has the considerable collateral
> benefit of making legacy data sets available for processing by
> arbitrary USS commands.
> 
> The next thing I'd like to see (but I don't do COBOL) is removal
> of contrived restrictions on the use of USS files and directories
> by applications using QSAM/BSAM/BPAM.  For example I'd like to
> be able to use a USS directory as SYSEXEC.  The only reason I
> can't is that Rexx makes a test (only on the first catenand) on
> DSORG that excludes USS directories.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
-- 
John McKown
Maranatha! <><

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

Re: Reversing the Catalog Definition entries

[Jake anderson]

Hello ,

"If you bring the datasets up in ISPF 3.4, just type a U in front of the
DSN(s) and when that completes, type a C"

Are there any sample JCLs which would perform the above stuff at once for
all 214 datasets.

Jake

On Wed, Apr 18, 2012 at 8:41 AM, retired mainframer <
retired-mainfra...@q.com> wrote:

> If you bring the datasets up in ISPF 3.4, just type a U in front of the
> DSN(s) and when that completes, type a C
>
> :>: -Original Message-
> :>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> :>: Behalf Of Jake anderson
> :>: Sent: Tuesday, April 17, 2012 7:48 PM
> :>: To: IBM-MAIN@bama.ua.edu
> :>: Subject: Reversing the Catalog Definition entries
> :>:
> :>: Hi All,
> :>:
> :>: I am just curious to know if we have indirectly cataloged one set of
> :>: volume
> :>: lets say ZX2RS2 to &SYSR2. Can we change back the entries in Master
> :>: Catalog
> :>: from &SYSR2 to ZX2RS2 ? Could anyone please advise me if such options
> :>: are
> :>: available to do so.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Reversing the Catalog Definition entries

[retired mainframer]

If you bring the datasets up in ISPF 3.4, just type a U in front of the
DSN(s) and when that completes, type a C

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
:>: Behalf Of Jake anderson
:>: Sent: Tuesday, April 17, 2012 7:48 PM
:>: To: IBM-MAIN@bama.ua.edu
:>: Subject: Reversing the Catalog Definition entries
:>:
:>: Hi All,
:>:
:>: I am just curious to know if we have indirectly cataloged one set of
:>: volume
:>: lets say ZX2RS2 to &SYSR2. Can we change back the entries in Master
:>: Catalog
:>: from &SYSR2 to ZX2RS2 ? Could anyone please advise me if such options
:>: are
:>: available to do so.

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

Re: GO TO "cobol"

[Clark Morris]

On 16 Apr 2012 14:32:30 -0700, in bit.listserv.ibm-main you wrote:

>Use of NEXT SENTENCE is as dangerous as GO TO.  Try using CONTINUE.
>
>The former takes you to the next period;  the latter takes you to the end 
>of the current conditional.  One missed period and 
>
>--
>
>I've seen many programs without a single period.  How they work is beyond
>my comprehension.  Of course, a paragraph name does imply a period.

All paragraphs have to end with a period.  

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

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

Re: GO TO "cobol"

[Clark Morris]

On 16 Apr 2012 14:25:19 -0700, in bit.listserv.ibm-main you wrote:

>I have many years' experience writing COBOL code and have used GO TO and
>THRU only as a means of exiting a paragraph.  I frequently code paragraph
>subroutines that perform a series of related edits, and would use them like
>this:
>
> Perform 2000-Validate-Input thru 2000-exit.
>*test resultant switch settings here... 
>
>
> 2000-Validate-Input.
>
> If some-test-here-failed
> Set indicator-switch to true
> Go to 2000-exit
> End-if.
>
> If some-other-test-fails
> Set indicator-different-switch to true
> Go to 2000-exit
> End-if.
>
>* Blah, blah, blah
>
>* When you get here, all tests are good and action can be taken
>
> 2000-exit.
> Exit.
>
>
>The THRU clause is only to support an "exit paragraph" ability.  Because I
>follow some rules with this technique, it has never caused me a problem.
>The rules?  They are simple:
>
>- Only "go to" the exit point for the current paragraph.  I never span.
>This means that the "go to" statements are always pointed downward - the
>same way my perform statements always point.
>
>- I verify that this rule is observed by F GO WORD in ISPF (with comments
>excluded).  Each time I find a GO, I then look for P'-' 8 to ensure that
>the exit paragraph is the next paragraph.
>
>I, too, believe that "thru" and "section" is a preference that can't be
>persuaded in most people.  I personally hate to use sections and view them
>as evil.  When forced to use sections, such as when performing an internal
>sort, I just code unreferenced "dummy" sections around my input and output
>sections.
>
>It would be nice if an "exit paragraph" statement existed.  When it does,
>I'll never need a THRU or GO TO again - and good riddance!
>
It has existed in the COBOL standard since 2002, just not in any IBM
compiler.  Add it to the list of SHARE requirements for functions that
exist in the 2002 standard.

Clark Morris

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

Re: GO TO "cobol"

[Clark Morris]

On 16 Apr 2012 11:02:51 -0700, in bit.listserv.ibm-main you wrote:

>A dirty myth about COBOL is the belief the THRU is required and that SECTIONs 
>are a good idea. Unless specifically required by SORT or something, I never 
>used either. It has been 20+ years since I did much COBOL. Haven't had the 
>pleasure of the newer constructs.

Nothing requires sections any more.  My comments on GO TO are based on
the compiler optimizations done for PERFORM and what GO TO does to
those optimizations.  Also the IF ... END-IF READ ... END-READ etc.
statements greatly reduce complexity.  If you don't believe that GO TO
can have an effect try compiling a program generated by CSP release 4
with all its GO TO statements with OPTIMIZE.  If the module is large
enough it can give the compiler real fits and chew CPU time
unbelievably.

Clark Morris 
>
>As to the OP's belief about performance, structured programming has never been 
>about performance, it is about understandability.
>
>Dave Gibney
>Information Technology Services
>Washington State University
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
>> Behalf Of McKown, John
>> Sent: Monday, April 16, 2012 5:28 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: GO TO "cobol"
>> 
>> Our use of GO TO is generally restricted to usage such as:
>> 
>>PERFORM I-P THRU I-P-EXIT UNTIL CONDITION.
>> 
>> I-P.
>> READ FILE AT END
>>  SET CONDITION TO TRUE
>>  GO TO I-P-EXIT
>> END-READ
>> ...
>> I-P-EXIT.
>> EXIT.
>> 
>> Otherwise, to avoid the GO TO, we'd need to do:
>> 
>> I-P.
>> READ FILE AT END
>>  SET CONDITION TO TRUE
>> END-READ
>> IF NOT CONDITION THEN
>> ...
>> END-IF.
>> I-P-EXIT.
>> EXIT.
>> 
>> Which I consider to be worse than the exit, so far as comprehension is
>> concerned.
>> 
>> --
>> John McKown
>> Systems Engineer IV
>> IT
>> 
>> Administrative Services Group
>> 
>> HealthMarkets®
>> 
>> 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® is the brand name for products underwritten and issued by
>> the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life
>> Insurance Company®, 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@bama.ua.edu] On Behalf Of Thomas Berg
>> > Sent: Monday, April 16, 2012 5:40 AM
>> > To: IBM-MAIN@bama.ua.edu
>> > Subject: SV: GO TO "cobol"
>> >
>> > An alternative is to have e g an 88-type LEAVE item that is
>> > checked for every code-block including all iterations and selections.
>> > (You set leave to true when wanting to do a "leave" type jump.)
>> >
>> >
>> >
>> > Regards,
>> > Thomas Berg
>> > __
>> > Thomas Berg   Specialist   AM/DQS   SWEDBANK AB (publ)
>> >
>> >
>> >
>> > > -Ursprungligt meddelande-
>> > > Från: IBM Mainframe Discussion List
>> > [mailto:IBM-MAIN@bama.ua.edu] För
>> > > Edward Jaffe
>> > > Skickat: den 16 april 2012 08:15
>> > > Till: IBM-MAIN@bama.ua.edu
>> > > Ämne: Re: GO TO "cobol"
>> > >
>> > > On 4/15/2012 10:31 PM, Wayne Bickerdike wrote:
>> > > > For devotees of Jackson Structured programming, the GOTO
>> > is a must for
>> > > > POSIT and ADMIT processing. Otherwise it can be messy
>> > avoiding a GOTO.
>> > >
>> > > The problem with GOTO is that the suitability of the target branch
>> > > location is
>> > > not enforced by the compiler according to any structured discipline.
>> > >
>> > > Premature terminations (posit/quit/admit) can almost always
>> > be handled
>> > > with
>> > > LEAVE-type statements or immediate return from a subroutine. Some
>> > > languages have
>> > > SIGNAL, EXIT, etc. which can help provide structured premature
>> > > termination for
>> > > larger routines without resorting to the dreaded GOTO.
>> > >
>> > > --
>> > > Edward E Jaffe
>> > > Phoenix Software International, Inc
>> > > 831 Parkview Drive North
>> > > El Segundo, CA 90245
>> > > 310-338-0400 x318
>> > > edja...@phoenixsoftware.com
>> > > http://www.phoenixsoftware.com/
>> > >
>> > >
>> > --
>> > > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>> >
>> > --
>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>> >
>> >
>> 

Reversing the Catalog Definition entries

[Jake anderson]

Hi All,

I am just curious to know if we have indirectly cataloged one set of volume
lets say ZX2RS2 to &SYSR2. Can we change back the entries in Master Catalog
from &SYSR2 to ZX2RS2 ? Could anyone please advise me if such options are
available to do so.

Jake

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

Re: GO TO "cobol"

[Clark Morris]

On 16 Apr 2012 13:46:08 -0700, in bit.listserv.ibm-main you wrote:

>IBM Mainframe Discussion List  wrote on 04/16/2012 
>10:57:47 AM:
>
>> From: Binyamin Dissen 
>
>> The elimination of GOTOs was to save people time at the cost of CPU 
>time.
>
>?
>
>> Obviously, if a procedure was called from several points ALTER GOTO 
>would
>> generate fewer instructions than perform.
>
>The last time I looked at a PMAP, the Cobol compiler implements PERFORM 
>exactly like an ALTERed GO TO, except that all addresses are stored in a 
>table.

Take a look at the optimized code where paragraphs can only be reached
by PERFORM.  In many cases the code for a PERFORM is actually the code
for the paragraph being PERFORMED.  

Clark Morris
>
>> But with GOTOless programming the logic is easier to read. There is no
>> question about how you got somewhere.
>
> agreed
>
>-
>The information contained in this communication (including any
>attachments hereto) is confidential and is intended solely for the
>personal and confidential use of the individual or entity to whom
>it is addressed. If the reader of this message is not the intended
>recipient or an agent responsible for delivering it to the intended
>recipient, you are hereby notified that you have received this
>communication in error and that any review, dissemination, copying,
>or unauthorized use of this information, or the taking of any
>action in reliance on the contents of this information is strictly
>prohibited. If you have received this communication in error,
>please notify us immediately by e-mail, and delete the original
>message. Thank you 
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: GO TO "cobol"

[Clark Morris]

On 16 Apr 2012 07:35:00 -0700, in bit.listserv.ibm-main you wrote:

>This topic I cannot resist...  Uggg...
>
>Having learned COBOL in the mid 70's, the instructor taught that PERFORM was 
>to be used only in situations where you wanted
>to do a certain routine at several locations in the program.  The teaching was 
>also about "straight line" programming.  Flow 
>Charts were also part of the curriculum.
>
>Having said that, I still use GO TO extensively, and have not kept up with the 
>"modern" programming extensions and constructs.
>I've had many instances in my career where a "structured" program has been 
>"straight lined" with extremely dramatic performance
>results.  Mostly I believe that knowing Assembler language and how the COBOL 
>compiler would generate the assembler code version
>of the program provided the reasons for my coding techniques.  I would write 
>the program as close to what the assembler code
>would be as possible.  This would usually provide some great performance at 
>run time (and at compile time).
>
>One example (out of several) was a program which normally took 4-6 hours to do 
>its magic.  When I re-wrote it due to the necessity
>of adding more functionality, I went ahead and "straight lined" it according 
>to the logic of what the program was supposed to do.
>When the re-write was finished, the new program took 20 minutes to run the 
>first time it was in production.  I have several other
>examples with these type of results.

What compiler were you working with?  What other changes did you make?
COBOL VS (the 1974 standard) had poor code generation for PERFORM and
PERFORM ... UNTIL was especially poor.  VS COBOL II V1R4 drastically
changed that with simplified linkage where paragraphs could only be
reached by PERFORM and in many cases PERFORMED paragraphs were moved
inline to eliminate the branching.  The compiler could detect where a
one byte field was initialized and never changed so it could use
immediate instructions (MVI, CLI) when the field was used in a MOVE or
COMPARE.  Making sure all sequential files had BLOCK 0 coded also did
wonders.

Clark Morris
>
>Also, CICS used to treat the "HANDLE CONDITION" API as a GO TO, not a perform. 
> Went to the Well in the early-mid 80's over that 
>one with a bunch of certain "whiz-kids" who were trained under the good 
>doctors premises.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: GO TO "cobol"

[Mike Schwab]

On Tue, Apr 17, 2012 at 5:21 PM, Shmuel Metz (Seymour J.)
> Listen to "Every OS Sucks" by 3 Dead Trolls in a Baggie.
>
> --
>     Shmuel (Seymour J.) Metz, SysProg and JOAT

Animated version.
http://www.youtube.com/watch?v=hg0iRd4i0qk
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: ZOS 1.13 SMPTABL Mystery

[Shmuel Metz (Seymour J.)]

In
<4c9510dff1800349929e187eaf4a7cc214ac73d...@exchange.classic.pchad.com>,
on 04/13/2012
   at 11:46 AM, "Dazzo, Matt"  said:

>I have installed Z1.13 and it's up and running in our test lpar.
>Seems dsn= SYS1.SMP.SMPTABL is not on the new res volume. I checked
>the CPAC alloc and restore jobs and can't find it in there either.
>Searched the migration guide and no mention of it there either.
>Anyone else run into this or have any ideas why this might be
>missing? Thanks Matt

Presumably an output PDS for file tailoring within the SMP/E dialogs.
You might want to make it a per-user data set.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In , on 04/16/2012
   at 05:57 PM, Binyamin Dissen  said:

>But with GOTOless programming the logic is easier to read.

Except when it's harder. The real issue is structuring the code so
that it's easier to read and maintain, not blindly following  a
theological dictum. If that requires more goto statements then I'll
cheerfully use them. Read "Structured Programming Using goto" (I'm not
sure of the spelling.)
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In
,
on 04/16/2012
   at 09:32 PM, Mike Schwab  said:

>TLA for ARMY Private FIrst Class.

Give me back my Air Force. I believe that the Marines also have the
rank.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc>, on
04/16/2012
   at 12:01 PM, "Staller, Allan"  said:

>BTW, I agree w/Dykstra. Maintaining a structured program is far
>easier than spaghetti code. 

False dichotomy. You can have spaghetti code without goto and you can
use goto judiciously without writing spaghetti code. You have to carve
the bird at the joints.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <4809508338399138.wa.paulgboulderaim@bama.ua.edu>, on
04/16/2012
   at 08:10 AM, Paul Gilmartin  said:

>Rexx is a nightmare here.

No. The signal statement in Rexx is not a go to. What is a nightmare
is using a hammer as a screwdriver. Not that Rexx doesn't have issues,
but what language doesn't?

Listen to "Every OS Sucks" by 3 Dead Trolls in a Baggie.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <1334665025.13456.yahoomai...@web180919.mail.ne1.yahoo.com>, on
04/17/2012
   at 05:17 AM, Lloyd Fuller  said:

>In 1969, and until sometime in the 1970s or later, the Army
>programming school  was at Fort Benjamin Harrison in Indiana.

Uncle Bennie's Rest Home. Indianapolis has a reputation as unfriendly,
but it was the only one of the three[2] training facilities I went
through where the local civilians treated us decently.

[2] The other two were Gordon and Jackson.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: IEL1CL not found

[Shmuel Metz (Seymour J.)]

In
,
on 04/17/2012
   at 08:18 AM, jagadishan perumal  said:

>Could anyone please point me to the right direction.

Where does SMP think it is? Is that library in the proclib
concatenation you're using?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: z/OS every two years (Official announcment)

[Shmuel Metz (Seymour J.)]

In ,
on 04/13/2012
   at 10:16 AM, "McKown, John"  said:

>I do like the PDFs. I have all the CICS and z/OS system PDFs
>downloaded to my PC and on my Kindle DX. I don't like reading them 
>on my PC due to the PDFs being designed to be read on a device in
>portrait orientation.

The monitor on my PC is landscape. I have no trouble reading PDF,
although I would rather have BOO.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

[Shmuel Metz (Seymour J.)]

In ,
on 04/11/2012
   at 12:32 PM, "McKown, John"  said:

>Given all the above facts, I wonder if it is time to abandon, in 
>our own code, the practice of indicating end-of-list by setting 
>the high order bit of the last parameter to '1'b.

Perhaps for new subroutines, but certainly not for anything intended
to be invoked from JCL.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Query about overcoming -- debunking, countering, and burying --mainframe myths

[Shmuel Metz (Seymour J.)]

In <4f84ecfe.7060...@gabegold.com>, on 04/10/2012
   at 10:31 PM, Gabe Goldberg  said:

>What are the worst -- most ridiculous, most outdated -- myths 
>you've recently heard?

Not recent, but a customer once approached me with a COBOL program
that was getting a program check. I asked what was in R14. Her
response blew me away: "But COBOL doesn't use registers."
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: SV: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In
,
on 04/16/2012
   at 03:42 PM, Thomas Berg  said:

>(BTW, How do You imagine the behavior if the Signal DID NOT trash 
>the DO nesting?

The Devil is in the details. Contrast Rexx with PL/I. In PL/I a SIGNAL
invokes an ON-unit as a subroutine. The On=unit can return to the code
following the SIGNAL, can SIGNAL another condition, or can include a
GOTO, which will pop the stack as appropriate. Note that in PL/I you
cannot do a GOTO into a DO loop from outside.

>I mean, of what use would that be?

Quite a bit if you do it the way PL/I does.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: z/OS every two years (Official announcment)

[Shmuel Metz (Seymour J.)]

In <1BA00CBB414DA34AA25ED82F4647CDE20621604B42@MAIL02.fisalan.nycnet>,
on 04/12/2012
   at 10:05 AM, "Sevetson, Phil"  said:

>Guys, there's this thing they call the Internet,

Really? Is it magic? Because if it isn't magic then it doesn't address
the issue. NTW, you might ask those who prefer Bookie how they obrain
their manuals/ You find that the answer includes more than CD and DVD.

>where you can get good documentation

FSVO good.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In ,
on 04/16/2012
   at 08:34 AM, "McKown, John"  said:

>Also remember that COBOL, at least originally, was supposed to be
>very English-like

Not to native Anglophones :-(
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: z/OS V1R13 testing after migration

[Linda Mooney]

Hi Alvaro, 

  

Along with your ServerPac, there are instructions for testing system 
components/products and a library,  *.SPAC.IVPLIB with some jobs in it.  There 
is also some info in the Installing Your Order manual.  

  

The migration guide has a lot of info about changes and things that you need to 
do.  If you search zOS install site:ibm.com and zOS migration site:share.org 
you should find helpful information there.  Also check the program directories 
for your products.  Run Health Checker in your test lpar.  It will help you 
discover any problems. 

  

Your shop should also have a PDS of local test jobs, and hopefully some 
documentation, from when the previous version of z/OS was installed there.  
Many shops keep the library of user developed IVPs in a separate PDS, and 
update it as needed for each install. I t probably has IVP or IVPLIB somewhere 
in the name. 





HTH, 

Linda 

- Original Message -




From: "Alvaro Guirao Lopez"  
To: IBM-MAIN@bama.ua.edu 
Sent: Monday, April 16, 2012 3:57:36 AM 
Subject: z/OS V1R13 testing after migration 

Sorry if this is a dup.. but I don't find nothing related in the list. 

Do you know of any presentation or someting similar from SHARE or others 
that talks about actions taken for testing z/OS V1R13 and products related 
to the operating system release after migration from V1R11 (or others)? 

-- 
Un saludo. 
Álvaro Guirao 

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

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

Re: IEHLIST LISTVTOC inconsistency

[Tony Harminc]

On 17 April 2012 18:37, Paul Gilmartin  wrote:
> On Tue, 17 Apr 2012 17:49:24 -0400, Tony Harminc wrote:

>>I doubt that the IEH utilities use DYNALLOC. They long predate the
>>very existence of DYNALLOC, and while they may, of course, have been
>>updated, I suspect they continue to use a combination of DADSM and
>>home-grown manipulation of control blocks.
>>
> Obviously, something changed between 1.11 and 1.12.
>>But of course there's no real way to tell in these OCO days, unless
>>some message or behaviour leaks the information.
>>
> In TSO:
>
> o preallocate SYSLIB to an arbitrary DSN.
> o CALL *(IEHLIST)
> o use BPXWDYN( 'INFO ...' ) to detect any change in allocation
>  of SYSLIB.
>
> (Or preallocate SYSLIB to a USS path.  DYNALLOC REUSE doesn't
> deallocate PATHs.  Analyze any failures.)

Or ask your local, friendly IBMer if any of the IEH... source contains
the strings "DYNALLOC" or "SVC 99". Not that it really matters, of
course.

Tony H.

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[Paul Gilmartin]

On Tue, 17 Apr 2012 16:29:13 -0600, Steve Comstock wrote:
>>
>> Cheers,
>> TomR>>  COBOL is the Language of the Future!<<
>
>So, in other words, you'll make the exclusion explicit instead of
>removing the restriction. :-)
>
>But, I gather from some of the discussions, and your comments, on
>this list, you are rather tied up with other compiler priorities
>these days.
>
>Hope all is well.
>
Errr...  Does that compiler not already contain code to read input
from legacy data sets in the case when it's invoked in batch,
or is it a completely different compiler?

What happens in the batch case if the copybook concatenation
contains a USS directory?

-- gil

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

Re: IEHLIST LISTVTOC inconsistency

[Paul Gilmartin]

On Tue, 17 Apr 2012 17:49:24 -0400, Tony Harminc wrote:
>
>>>Actually, they probrably would document that SYSLIB DD name cannot be
>>>used to with z/OS 1.12 and above to allow for testing alternate
>>>versions of the program.
>>>
>> Are you thinking, rather, perhaps, of STEPLIB?
>>
>> Its likely that they internally DYNALLOC DD(SYSLIB) REUSE, for whatever
>> purpose.  They ought to remove the REUSE key, allowing a "IKJ56246I"
>> FILE in USE" message to appear and use a generated DDNAME (best).
>> A poor second is to document the restriction.
>
>I doubt that the IEH utilities use DYNALLOC. They long predate the
>very existence of DYNALLOC, and while they may, of course, have been
>updated, I suspect they continue to use a combination of DADSM and
>home-grown manipulation of control blocks.
> 
Obviously, something changed between 1.11 and 1.12.
>But of course there's no real way to tell in these OCO days, unless
>some message or behaviour leaks the information.
>
In TSO:

o preallocate SYSLIB to an arbitrary DSN.
o CALL *(IEHLIST)
o use BPXWDYN( 'INFO ...' ) to detect any change in allocation
  of SYSLIB.

(Or preallocate SYSLIB to a USS path.  DYNALLOC REUSE doesn't
deallocate PATHs.  Analyze any failures.)

-- gil

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[Steve Comstock]

On 4/17/2012 4:04 PM, Tom Ross wrote:

On 4/16/2012 3:26 PM, McKown, John wrote:

If so, have you figured out how to specify a PDS as an "include" or
"copybook"source? The documentation for this command basically stinks.



There is an -I switch. But it apparently only accepts UNIX path

specifications.

The ld command (binder) accepts a PDS name via -L "//pds.name". The as

command

(HLASM) and C compilers accept a -I "//pds.name". I may end up writing

my own

version of the "cob2" command, if I really decide that I want to compile

COBOL

from the UNIX shell. I'll likely model it after the as command.


Yes. I discuss this command in our course "Developing Applications for
z/OS UNIX". But you're right, the doc is very poor. The assumption seems
to be that copy books must be in HFS directories and my experiments
produce error messages that would support that.

In a way, that's too bad. OTOH, I, too, was assuming that copy books
would reside in HFS directories so I had never tried to access copy
books as members of a PDS before.

You would think that if you used the classic clue that a library was
a PDS/E, the compiler could figure it out. Maybe:

export SYSLIB="//'SCOMSTO.U520.LIBRARY'"

which I tried, and the message from the compile comes back:

  LineID  Message code  Library phase message text
  24  IGYLI0049-S   The "COPY" library "SCOMSTO.U520.LIBRARY/APODEFS"
was not
found.  Skipped to the period terminating the
"COPY"
statement.

so it was pretty clearly expecting (nay: requiring) a z/OS UNIX
file, not a PDS.

I'm copying this over to ibm-main, too, as Tom Ross occasionally
follows that group so maybe he will chime in with some info.


Well, I actually ALWAYS follow this group, but via digest, so by
the time I see the COBOL questions someone on IBMMAIN has already
given the answer that I would have given!  A perfect example is the
GO TO discussion where the poster did not use the "NOT AT END" phrase
of READ.  Thank you listers for being so COBOL savvy!

On the topic of where your source can be for the cob2 command, it is
documented in the Programming Guide.  It did take me a minute to
find it, but the location seems to make sense to me.  In COBOL V4R2
version, see "Chapter 15. Compiling under z/OS UNIX", under the
heading "Setting environment variables under z/OS UNIX":

SYSLIB
Specify paths to directories to be used in searching for COBOL copybooks
if you do not specify an explicit library-name in the COPY statement.
Separate multiple paths with a colon. Paths are evaluated in order from the
first path to the last in the export command. If you set the variable with
multiple files of the same name, the first located copy of the file is used.
For COPY statements in which you have not coded an explicit library-name,
the compiler searches for copybooks in this order:
1. In the current directory
2. In the paths you specify with the -I cob2 option
3. In the paths you specify in the SYSLIB environment variable


It clearly says only directories and paths, but I suppose a confirmation
that datasets are not supported would be nice.  I will try to get that into
the next version of the Programming Guide.  If anyone has a better suggestion
for where this confirmation would go, let me know!

Cheers,
TomR>>  COBOL is the Language of the Future!<<


So, in other words, you'll make the exclusion explicit instead of
removing the restriction. :-)

But, I gather from some of the discussions, and your comments, on
this list, you are rather tied up with other compiler priorities
these days.

Hope all is well.

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[Paul Gilmartin]

On Tue, 17 Apr 2012 13:07:18 -0600, Steve Comstock wrote:

>On 4/17/2012 12:53 PM, McKown, John wrote:
>> As the OP, I thought I'm mention that I finally got the z/OS NFS server to
>allow me to mount a high-level onto a z/OS UNIX subdirectory on the same 
>system.
>
>Clever and resourceful. But certainly just a workaround for
>the situation: you would like the compilers to be able to
>use MVS data sets directly for SYSLIB (and other DD names).
>
More than "just a workaround".  It has the considerable collateral
benefit of making legacy data sets available for processing by
arbitrary USS commands.

The next thing I'd like to see (but I don't do COBOL) is removal
of contrived restrictions on the use of USS files and directories
by applications using QSAM/BSAM/BPAM.  For example I'd like to
be able to use a USS directory as SYSEXEC.  The only reason I
can't is that Rexx makes a test (only on the first catenand) on
DSORG that excludes USS directories.

-- gil

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[Tom Ross]

>On 4/16/2012 3:26 PM, McKown, John wrote:
>> If so, have you figured out how to specify a PDS as an "include" or
>> "copybook"source? The documentation for this command basically stinks.
>
>> There is an -I switch. But it apparently only accepts UNIX path
>specifications.
>> The ld command (binder) accepts a PDS name via -L "//pds.name". The as
>command
>> (HLASM) and C compilers accept a -I "//pds.name". I may end up writing
>my own
>> version of the "cob2" command, if I really decide that I want to compile
>COBOL
>> from the UNIX shell. I'll likely model it after the as command.
>
>Yes. I discuss this command in our course "Developing Applications for
>z/OS UNIX". But you're right, the doc is very poor. The assumption seems
>to be that copy books must be in HFS directories and my experiments
>produce error messages that would support that.
>
>In a way, that's too bad. OTOH, I, too, was assuming that copy books
>would reside in HFS directories so I had never tried to access copy
>books as members of a PDS before.
>
>You would think that if you used the classic clue that a library was
>a PDS/E, the compiler could figure it out. Maybe:
>
>export SYSLIB="//'SCOMSTO.U520.LIBRARY'"
>
>which I tried, and the message from the compile comes back:
>
>  LineID  Message code  Library phase message text
>  24  IGYLI0049-S   The "COPY" library "SCOMSTO.U520.LIBRARY/APODEFS"
>was not
>found.  Skipped to the period terminating the
>"COPY"
>statement.
>
>so it was pretty clearly expecting (nay: requiring) a z/OS UNIX
>file, not a PDS.
>
>I'm copying this over to ibm-main, too, as Tom Ross occasionally
>follows that group so maybe he will chime in with some info.

Well, I actually ALWAYS follow this group, but via digest, so by
the time I see the COBOL questions someone on IBMMAIN has already
given the answer that I would have given!  A perfect example is the
GO TO discussion where the poster did not use the "NOT AT END" phrase
of READ.  Thank you listers for being so COBOL savvy!

On the topic of where your source can be for the cob2 command, it is
documented in the Programming Guide.  It did take me a minute to
find it, but the location seems to make sense to me.  In COBOL V4R2
version, see "Chapter 15. Compiling under z/OS UNIX", under the
heading "Setting environment variables under z/OS UNIX":

SYSLIB
Specify paths to directories to be used in searching for COBOL copybooks
if you do not specify an explicit library-name in the COPY statement.
Separate multiple paths with a colon. Paths are evaluated in order from the
first path to the last in the export command. If you set the variable with
multiple files of the same name, the first located copy of the file is used.
For COPY statements in which you have not coded an explicit library-name,
the compiler searches for copybooks in this order:
1. In the current directory
2. In the paths you specify with the -I cob2 option
3. In the paths you specify in the SYSLIB environment variable


It clearly says only directories and paths, but I suppose a confirmation
that datasets are not supported would be nice.  I will try to get that into
the next version of the Programming Guide.  If anyone has a better suggestion
for where this confirmation would go, let me know!

Cheers,
TomR  >> COBOL is the Language of the Future! <<

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

Re: brand new CF LPAR

[Skip Robinson]

Each structure definition in the CFRM policy requires a PREFLIST to 
indicate where to allocate the structure. The PREFLIST contains one or 
more names as defined at the top of the policy. Although IBM recommends 
that NAME match the CF LPAR where it resides, that correspondence is not 
required. (I never even saw that recommendation until just now when I 
looked in the book.) For 15 years we have always used NAME to match the 
CEC because we name ICF LPARs by the sysplex to which they belong. That 
is, sysplex X will use LPAR CFPLEXX on all participating CECs. NAME would 
not be unique if we tried to use the ICF LPAR name. 

Bottom line is that NAME can be anything you choose as long as it follows 
the syntax rules. I wish I could tell you that I have done this exact same 
thing, but it should work fine. *Add* a new CF NAME to your policy like 
this:

CF NAME(some-unique-name-of-your-choosing) 
   TYPE(new-CEC-type)
   SEQUENCE(new-serial-number)
   PARTITION(new-LPAR-number)
   ...
 
For each structure, include PREFLIST(old-name,new-name). Today only 
old-name will be found at IPL, so all structures will allocate there. 
After installing the new box, only new-name will be found, so that's where 
all structures will allocate. You will be just fine today and after the 
install. It can't hurt to try this now. If the CFRM policy compiles OK, 
you're 80% of the way there. Then activate the policy: SETXCF 
START,POL,TYPE=CFRM, POLNM=new-policy-name. If it activates with no 
errors, you're pretty much guaranteed that the same policy will work fine 
with the new CEC in place barring typos in CF definition. When you're all 
done, remove old-name from your policy. 

We've always had multiple CECs, but the principle is the same. We recently 
replaced both CECs on the floor using a similar strategy. At no point did 
we have to IPL into an untested configuration. 

.
.
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:   Munif Sadek 
To: IBM-MAIN@bama.ua.edu
Date:   04/16/2012 10:21 PM
Subject:Re: brand new CF LPAR
Sent by:IBM Mainframe Discussion List 



Thank you all.
Mr Kawkabani, I will use CFRMPOL to refer to newly created policy. What 
about ARM and SFM policies that I have created using IXCMIAPU and are 
named differently. How can I use them.
Still searching for how to create new CDS, BPXMCDS, LOGR (hundreds of 
structures)and WLM policies and how to make system to use them right from 
the IPL.. 

Mr Robinson, My problem is I have only one ICF partition on each boxes 
(Old and New) and will not have cross coupling facility links. Both of the 
CF names are COUPL01. Can I format CFRM Policy with duplicate CF NAME 
COUPL01 for each process types (2818 and 2086, serial number will remain 
the same). If it is possible I can use same CFRM policy and before 
shutting down the last LPAR for processor migration, I can change CF 
configuration to match the new processor.

I am planning to bring in sandbox LPAR  in the plex first and should be 
able to use FORCE command to get the Coupling facility correct before 
bringing in any proper systems in the PLEX..i do agree its risky and need 
guidance. 
Thaks once again for you valuable suggestion, its much appreciated..

Regards,
 Munif.


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

Re: IEHLIST LISTVTOC inconsistency

[Tony Harminc]

On 16 April 2012 23:32, Paul Gilmartin  wrote:
> On Mon, 16 Apr 2012 21:37:54 -0500, Mike Schwab wrote:
>>>
>>Actually, they probrably would document that SYSLIB DD name cannot be
>>used to with z/OS 1.12 and above to allow for testing alternate
>>versions of the program.
>>
> Are you thinking, rather, perhaps, of STEPLIB?
>
> Its likely that they internally DYNALLOC DD(SYSLIB) REUSE, for whatever
> purpose.  They ought to remove the REUSE key, allowing a "IKJ56246I"
> FILE in USE" message to appear and use a generated DDNAME (best).
> A poor second is to document the restriction.

I doubt that the IEH utilities use DYNALLOC. They long predate the
very existence of DYNALLOC, and while they may, of course, have been
updated, I suspect they continue to use a combination of DADSM and
home-grown manipulation of control blocks.

But of course there's no real way to tell in these OCO days, unless
some message or behaviour leaks the information.

Tony H.

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

Re: IEHLIST LISTVTOC inconsistency

[Gord Tomlin]

The volumes are 3390. The rest of the information is in the OP. A PMR 
has been submitted.



--

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

On 2012-04-17 07:36, Veilleux, Jon L wrote:

Do you have any specifics? What difference are you seeing? What kind of volume? 
Etc.
I would like to test on our systems
Thanks,
Jon

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
John Eells
Sent: Tuesday, April 17, 2012 7:25 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEHLIST LISTVTOC inconsistency

Please open a PMR.

Gord Tomlin wrote:

I just ran into a situation where IEHLIST is providing different
results for the same volume depending upon whether it is run from a
z/OS 1.11 system or a z/OS 1.13 system.



--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

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




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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[Jerry Whitteridge]

Awesome - glad we could get it worked out.



Jerry Whitteridge
Lead Systems Programmer
Safeway Inc.
925 951 4184

If you feel in control
you just aren't going fast enough.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
McKown, John
Sent: Tuesday, April 17, 2012 11:54 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

As the OP, I thought I'm mention that I finally got the z/OS NFS server to 
allow me to mount a high-level onto a z/OS UNIX subdirectory on the same 
system. I could then successfully use the cob2 command to compile a COBOL 
program which did a COPY CEEIGZCT from the mounted subdirectory. I mounted them 
at /$SYSNAME/nfs-legacy/. I.e. I put -I /\$SYSNAME/nfs-legacy/cee/SCEESAMP 
on my cob2 command. 

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

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


"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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Is there a way to cause SRB to TCB percolation if an XCF exit fails?

[Peter Relson]

As Mark Brooks basically said, with current functionality, the SRB exit 
routine must issue CALLRTM TYPE=ABTERM,RETRY=NO (whether from its mainline 
or its own recovery) if the XCF module that calls the exit routine is not 
to retry. If the exit routine wants this to be predictable, it would be 
well served to set up an FRR as just about the first thing it does.

Peter Relson
z/OS Core Technology Design

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

Re: GO TO "cobol"

[Lloyd Fuller]

When I went in 1969, we used a 1401 with 4 tape drives.  We were taught COBOL 
but could not compile:  the COBOL compiler for the 1401 needed either disk or 
at 
least 6 tape drives.  


We also learned to "program" PCM and two Univac SAAL computers that were in use 
by the Army at the time.

Lloyd



- Original Message 
From: Ed Finnell 
To: IBM-MAIN@bama.ua.edu
Sent: Tue, April 17, 2012 2:38:44 PM
Subject: Re: GO TO "cobol"

I didn't get there 'til '76. They had a CDC 3300 as the main record keeper  
with somebody's MassStor and several ancillary processors. I didn't notice 
the  unit record equipment just the sound of a drum bouncing around in the 
bottom of  the cage. The programming course was taught on DOS under VM(Lt. 
Farmer  participated in SHARE).


In a message dated 4/17/2012 9:27:22 A.M. Central Daylight Time,  
leful...@sbcglobal.net writes:

Army  Finance Center there.  I think that they used  Unisys.



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

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

Re: Origins of numeric assignation of z196 & z114

[Pommier, Rex R.]

Kid-die  noun,

1.  In mainframe parlance, anybody of age less than 50.



Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
R.S.
Sent: Tuesday, April 17, 2012 2:07 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Origins of numeric assignation of z196 & z114

W dniu 2012-04-17 18:53, Elardus Engelbrecht pisze:
[...]
> Sh, kiddies are reading this and we greybeards must 
> behave. ;-D

Kiddies here? Are you KIDDING?

This is mainframe list! Avg member still remember Ford T premiere 


--
Radoslaw Skorupka
Lodz, Poland


--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorised to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 168.410.984 zotych.

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

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[McKown, John]

Definitely I would prefer that the command directly supported PDS & PDSE 
datasets. NFS is a horrible overhead to me, being a CPU miser.

-- 
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@bama.ua.edu] On Behalf Of Steve Comstock
> Sent: Tuesday, April 17, 2012 2:07 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Anybody use the "cob2" command on a UNIX shell 
> to compile COBOL?
> 
> On 4/17/2012 12:53 PM, McKown, John wrote:
> > As the OP, I thought I'm mention that I finally got the 
> z/OS NFS server to
> allow me to mount a high-level onto a z/OS UNIX subdirectory 
> on the same system.
> I could then successfully use the cob2 command to compile a 
> COBOL program which
> did a COPY CEEIGZCT from the mounted subdirectory. I mounted them at
> /$SYSNAME/nfs-legacy/. I.e. I put -I 
> /\$SYSNAME/nfs-legacy/cee/SCEESAMP on
> my cob2 command.
> 
> Clever and resourceful. But certainly just a workaround for
> the situation: you would like the compilers to be able to
> use MVS data sets directly for SYSLIB (and other DD names).
> 
> 
> >
> > --
> > 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
> >
> > 
> --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
> 
> 
> -- 
> 
> Kind regards,
> 
> -Steve Comstock
> The Trainer's Friend, Inc.
> 
> 303-355-2752
> http://www.trainersfriend.com
> 
> * To get a good Return on your Investment, first make an investment!
>+ Training your people is an excellent investment
> 
> * Try our tool for calculating your Return On Investment
>  for training dollars at
>http://www.trainersfriend.com/ROI/roi.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[Steve Comstock]

On 4/17/2012 12:53 PM, McKown, John wrote:

As the OP, I thought I'm mention that I finally got the z/OS NFS server to

allow me to mount a high-level onto a z/OS UNIX subdirectory on the same system.
I could then successfully use the cob2 command to compile a COBOL program which
did a COPY CEEIGZCT from the mounted subdirectory. I mounted them at
/$SYSNAME/nfs-legacy/. I.e. I put -I /\$SYSNAME/nfs-legacy/cee/SCEESAMP on
my cob2 command.

Clever and resourceful. But certainly just a workaround for
the situation: you would like the compilers to be able to
use MVS data sets directly for SYSLIB (and other DD names).




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

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




--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

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

Re: Origins of numeric assignation of z196 & z114

[R.S.]

W dniu 2012-04-17 18:53, Elardus Engelbrecht pisze:
[...]

Sh, kiddies are reading this and we greybeards must behave. 
;-D


Kiddies here? Are you KIDDING?

This is mainframe list! Avg member still remember Ford T premiere 


--
Radoslaw Skorupka
Lodz, Poland


--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

Re: SMS QUESTION

[R.S.]

My guess: you tried to define dataset > 4GB limit (*).

RC 140 RSN 110 say about it. To Allan: I would suggest to use regular 
IBM documentation and regular BookManager search utility ;-)

I'm serious: 3 clicks and you have the answer.

I don't know what is the reason of the problem, but it can be difference 
in DC definitions (do not confuse with ACS routines).


(*) Remarks:
1. There are other reasons for 140-110, 4GB limit is only one of them.
2. 4GB limit is a little bit tricky: this is limit of RBA, but total 
size in tracks x track size can be slightly bigger than 4GB. The real 
allocation limit is:

2^32 / CISZ -> integer number of CI's
number of CI's / CI/CA -> integer number of CA's
(in both case you truncate the value, i.e. 1023,2837 -> 1023)
number of CA's * ca size in track = maximum size of VSAM non-EA.

--
Radoslaw Skorupka
Lodz, Poland




W dniu 2012-04-17 18:13, willie bunter pisze:

I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster 
recovery.  The SMS rules - ACS or DC, MC ,SC&  SG - are the same as in our 
production system.  However I could not understand the reason for this problem.  As 
a work around I defined the MCDS to use 4,000
cylinders on HSM001 which is a MOD-9.  What is also suprising is that the BCDS 
which is also VSAM EXTENDED worked fine.

Below is the output of the failing job.

   DEFINE CLUSTER -
   (NAME(SYS2.MCDS)  -
   VOLUMES(HSM001)  -
   CYLINDERS(8000)  -
   RECORDSIZE(435 2040)  FREESPACE(0  0) -
   INDEXED  KEYS(44  0)   SHAREOPTIONS(3 3) -
   SPEED BUFFERSPACE(530432) -
   UNIQUE   NOWRITECHECK)  -
   DATA  -
 (NAME(SYS2.MCDS.DATA) -
   CONTROLINTERVALSIZE(12288)) -
   INDEX  -
 (NAME(SYS2.MCDS.INDEX) -
   CONTROLINTERVALSIZE(2048))
0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET
  SYS2.MCDS
  RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV
  IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING
  RETURN CODE 140 REASON CODE 110
  THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU
  SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT
  SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025
  IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET
  SYS2.MCDS
0IDC3014I CATALOG ERROR
  IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS
  IDC3009I IGG0CLEV-110
1IDCAMS  SYSTEM SERVICES   TIME: 
19:20:1304/02/12 PAGE  2
0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

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




--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[McKown, John]

As the OP, I thought I'm mention that I finally got the z/OS NFS server to 
allow me to mount a high-level onto a z/OS UNIX subdirectory on the same 
system. I could then successfully use the cob2 command to compile a COBOL 
program which did a COPY CEEIGZCT from the mounted subdirectory. I mounted them 
at /$SYSNAME/nfs-legacy/. I.e. I put -I /\$SYSNAME/nfs-legacy/cee/SCEESAMP 
on my cob2 command. 

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

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

Re: GO TO "cobol"

[Ed Finnell]

I didn't get there 'til '76. They had a CDC 3300 as the main record keeper  
with somebody's MassStor and several ancillary processors. I didn't notice 
the  unit record equipment just the sound of a drum bouncing around in the 
bottom of  the cage. The programming course was taught on DOS under VM(Lt. 
Farmer  participated in SHARE).
 
 
In a message dated 4/17/2012 9:27:22 A.M. Central Daylight Time,  
leful...@sbcglobal.net writes:

Army  Finance Center there.  I think that they used  Unisys.



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

Re: SMS QUESTION

[Hervey Martinez]

Whatever DataClass is being assigned to the MCDS, it is not defined with 
"extended addressing"


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
willie bunter
Sent: Tuesday, April 17, 2012 12:14 PM
To: IBM-MAIN@bama.ua.edu
Subject: SMS QUESTION

I encountered the problem with defining a VSAM EXTENDED dsn at a recent 
disaster recovery.  The SMS rules - ACS or DC, MC ,SC & SG - are the same as in 
our production system.  However I could not understand the reason for this 
problem.  As a work around I defined the MCDS to use 4,000
cylinders on HSM001 which is a MOD-9.  What is also suprising is that the BCDS 
which is also VSAM EXTENDED worked fine.  
 
Below is the output of the failing job.
 
  DEFINE CLUSTER -   
  (NAME(SYS2.MCDS)  -
  VOLUMES(HSM001)  -  
  CYLINDERS(8000)  -  
  RECORDSIZE(435 2040)  FREESPACE(0  0) -     
  INDEXED  KEYS(44  0)   SHAREOPTIONS(3 3) -     
  SPEED BUFFERSPACE(530432) -    
  UNIQUE   NOWRITECHECK)  -   
  DATA  -    
    (NAME(SYS2.MCDS.DATA) -   
  CONTROLINTERVALSIZE(12288)) -      
  INDEX  -    
    (NAME(SYS2.MCDS.INDEX) -     
  CONTROLINTERVALSIZE(2048))  
0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET
 SYS2.MCDS
 RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV
 IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING
 RETURN CODE 140 REASON CODE 110
 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU
 SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT
 SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025
 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET
 SYS2.MCDS
0IDC3014I CATALOG ERROR
 IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS
 IDC3009I IGG0CLEV-110
1IDCAMS  SYSTEM SERVICES   TIME: 
19:20:13    04/02/12 PAGE  2
0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

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

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[Mark Zelden]

On Tue, 17 Apr 2012 12:35:19 -0500, Paul Gilmartin  wrote:

>On Tue, 17 Apr 2012 10:59:59 -0500, Mark Zelden wrote:
>>
>>I ran an exec similar to this from TSO to mount the PDSE on the local system:
>>
>>/* rexx */
>>Address TSO
>> "MOUNT FILESYSTEM(NFS_ZELD) TYPE(NFS)" ,
>> "MOUNTPOINT('/u/zelden/testnfs') " ,
>> "PARM('SYST:""ZELDEN.TEST.PDSE,text"",xlat(Y)') "
>>
>Can you automount?

Don't know.  Never tried nor looked into it.  I put required NFS mounts for 
production
(needed for distributed unix) either at the end of /etc/rc or into a  script 
executed at 
the end of /etc/rc and use the "mountx" rexx shell script provided in the
/samples directory.


>
>How do permissions work?  (From Solaris we use mvslogin.)
>Ideally, on a single system it should be transparent to RACF:
>Whatever permissions you have on a data set should be
>available when it's mounted as a filesystem.
>

Different options.  RTFM.

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[Kirk Wolf]

To the original question, you should be able to use a Unix directory and
files in place of a PDS or PDSE in any program (with limitations), since
BPAM provides simulation for these.  Details can be found in "z/OS DFSMS
Using Datasets" under "Processing z/OS Unix files" -
http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dgt2d440/3.9?DT=20050602124524

So, allocate the equivalent of SYSLIB as a contenation with one DD pointing
to a Unix directory and invoke the COBOL compiler.   Even in the absence of
a shell command front-end, you could write your own REXX shell script to do
allocations via BPXWDYN and then invoke the COBOL compiler with LINKMVS.
 Similarly, it should not be difficult to write a REXX shell script for
FORTRAN.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[Paul Gilmartin]

On Tue, 17 Apr 2012 10:59:59 -0500, Mark Zelden wrote:
>
>I ran an exec similar to this from TSO to mount the PDSE on the local system:
>
>/* rexx */
>Address TSO
> "MOUNT FILESYSTEM(NFS_ZELD) TYPE(NFS)" ,
> "MOUNTPOINT('/u/zelden/testnfs') " ,
> "PARM('SYST:""ZELDEN.TEST.PDSE,text"",xlat(Y)') "
> 
Can you automount?  

How do permissions work?  (From Solaris we use mvslogin.)
Ideally, on a single system it should be transparent to RACF:
Whatever permissions you have on a data set should be
available when it's mounted as a filesystem.


>You can change "ZELDEN.TEST.PDSE"  to "ZELDEN.TEST" in the mount parm, then 
>all my data sets
>starting ZELDEN.TEST are mounted under /u/zelden/testnfs/  and the PDSE 
>members fall under
>/u/zelden/testnfs/PDSE/*.
>
Can you strip the parm to null string so all exported
data sets can be mounted?  (This is how we mount
data sets on Solaris.)


>My export looks like this, so I can write to that PDSE as well:
>
>ZELDEN-access=SYST|SYSX,rw=SYST|SYSX

Thanks,
gil

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

Re: SMS QUESTION

[Staller, Allan]

Apparently you have already looked up the relevant return code/reason code 
(IDC3009I RC140 RSN110). Lots of hits in IBM DB, for RC140, but none w/RSN110

0) Was SMS fully activated w/o errors at the time?
1) is the original dataset SMS managed? And Extended format?
2) Are you sure of you SMS routines? What happens does the ACS test facility 
say about your allocation? Is HSM001 a member of the SG? IS HSM001 formatted as 
a mod-9?
3) explicitly specify a DC w/extended attribute in the define.

If all of the above are true, open a PMR.

Al Staller | Z Systems Programmer | KBM Group | (Tel) 972 664 3565 | 
allan.stal...@kbmg.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
willie bunter
Sent: Tuesday, April 17, 2012 11:14 AM
To: IBM-MAIN@bama.ua.edu
Subject: SMS QUESTION

I encountered the problem with defining a VSAM EXTENDED dsn at a recent 
disaster recovery.  The SMS rules - ACS or DC, MC ,SC & SG - are the same as in 
our production system.  However I could not understand the reason for this 
problem.  As a work around I defined the MCDS to use 4,000
cylinders on HSM001 which is a MOD-9.  What is also suprising is that the BCDS 
which is also VSAM EXTENDED worked fine.  
 
Below is the output of the failing job.
 
  DEFINE CLUSTER -   
  (NAME(SYS2.MCDS)  -
  VOLUMES(HSM001)  -  
  CYLINDERS(8000)  -  
  RECORDSIZE(435 2040)  FREESPACE(0  0) -     
  INDEXED  KEYS(44  0)   SHAREOPTIONS(3 3) -     
  SPEED BUFFERSPACE(530432) -    
  UNIQUE   NOWRITECHECK)  -   
  DATA  -    
    (NAME(SYS2.MCDS.DATA) -   
  CONTROLINTERVALSIZE(12288)) -      
  INDEX  -    
    (NAME(SYS2.MCDS.INDEX) -     
  CONTROLINTERVALSIZE(2048))  
0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET
 SYS2.MCDS
 RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV
 IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING
 RETURN CODE 140 REASON CODE 110
 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU
 SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT
 SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025
 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET
 SYS2.MCDS
0IDC3014I CATALOG ERROR
 IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS
 IDC3009I IGG0CLEV-110
1IDCAMS  SYSTEM SERVICES   TIME: 
19:20:13    04/02/12 PAGE  2
0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

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

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

Re: Origins of numeric assignation of z196 & z114

[Elardus Engelbrecht]

R. Skorupka wrote:

>I have never heard someone saying: I'm using Ford product 2817-M15 known as 
>z196...

Neither me too, but I agree 101% with what you said. 

The same here, when we are talking about Hilux, it is about Toyota DoubleCab 
Bakkie. (Bakkie - pickup truck)

 ... and car thieves are loving this car ...   ;-/


Enjoy this trivia about Hilux at South Pole in around 2010 (articles plus good 
photos):

http://www.iol.co.za/motoring/cars/toyota/local-hilux-reaches-south-pole-1.876513
http://www.4x4offroads.com/toyota-hilux-south-pole.html

>BTW: Let's leave it. My primary goal was to explain the meaning of 196 and 114 
>and I did it. 

You achieved your goal with flying colours.

>The rest is my humble opinion. I wish I would start Cindy or logon to 
>Jennifer... ;-)

Sh, kiddies are reading this and we greybeards must behave. 
;-D

:-D   :-D

Groete / Greetings
Elardus Engelbrecht

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

Re: ADR938E - PROBLEM WITH FASTREPLICATION

[Pommier, Rex R.]

Hmm, the RC=1 is odd, especially seeing that you found the problem 
3390-27-->3390-9.  I would have expected it to have sent back a return code 2 
indicating a problem on the target.

I wonder what would have happened if you had changed it to FR(PREF) instead of 
FR(REQ).  I know it would have tried to copy everything because you wouldn't 
have been able to do the FCNC parm, but it might have pointed out the size 
mismatch more quickly.

In any case, glad you found the problem.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
John Dawes
Sent: Tuesday, April 17, 2012 10:36 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADR938E - PROBLEM WITH FASTREPLICATION

Rex,

My apologies, I truncated the message.  Here it is in its entirety:

ADR006I (052)-STEND(01), 2012.106 08:41:32 EXECUTION BEGINS
ADR918I (052)-DDTFP(01), FAST REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1, 
RETURN CODE 1
ADR938E (052)-DDTFP(01), FASTREPLICATION(REQUIRED) WAS SPECIFIED BUT FAST 
REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1
ADR006I (052)-STEND(02), 2012.106 08:41:32 EXECUTION ENDS
ADR013I (052)-CLTSK(01), 2012.106 08:41:32 TASK COMPLETED WITH RETURN CODE 0008




From: "Pommier, Rex R." 
To: IBM-MAIN@bama.ua.edu
Sent: Monday, 16 April 2012 2:10 PM
Subject: Re: ADR938E - PROBLEM WITH FASTREPLICATION

Is that all you got?  The messages manual says that there should have been a 
reason code with the ADR918I message.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
John Dawes
Sent: Saturday, April 14, 2012 6:18 PM
To: IBM-MAIN@bama.ua.edu
Subject: ADR938E - PROBLEM WITH FASTREPLICATION

G'Day,

I am trying to figure out this problem.  I checked the error message but I was 
unable to figure out what I should do or why the problem occurred.

ADR918I (052)-DDTFP(01), FAST REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1
ADR938E (052)-DDTFP(01), FASTREPLICATION(REQUIRED) WAS SPECIFIED BUT FAST 
REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1
ADR006I (052)-STEND(02), 2012.105 02:34:11 EXECUTION ENDS

Below is my jcl:

//STEP1EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440
//SYSPRINT  DD  SYSOUT=*
//SYSINDD  *
COPY FULL INDYNAM(RXTRS1) OUTDYNAM(@@883C) ALLE ALLD(*) -
FASTREPLICATION(REQUIRED) FCNOCOPY DUMPCONDITIONING ADMIN PURGE

Any suggestions?


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

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

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

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

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

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

SMS QUESTION

[willie bunter]

I encountered the problem with defining a VSAM EXTENDED dsn at a recent 
disaster recovery.  The SMS rules - ACS or DC, MC ,SC & SG - are the same as in 
our production system.  However I could not understand the reason for this 
problem.  As a work around I defined the MCDS to use 4,000
cylinders on HSM001 which is a MOD-9.  What is also suprising is that the BCDS 
which is also VSAM EXTENDED worked fine.  
 
Below is the output of the failing job.
 
  DEFINE CLUSTER -   
  (NAME(SYS2.MCDS)  -
  VOLUMES(HSM001)  -  
  CYLINDERS(8000)  -  
  RECORDSIZE(435 2040)  FREESPACE(0  0) -     
  INDEXED  KEYS(44  0)   SHAREOPTIONS(3 3) -     
  SPEED BUFFERSPACE(530432) -    
  UNIQUE   NOWRITECHECK)  -   
  DATA  -    
    (NAME(SYS2.MCDS.DATA) -   
  CONTROLINTERVALSIZE(12288)) -      
  INDEX  -    
    (NAME(SYS2.MCDS.INDEX) -     
  CONTROLINTERVALSIZE(2048))  
0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET
 SYS2.MCDS
 RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV
 IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING
 RETURN CODE 140 REASON CODE 110
 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU
 SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT
 SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025
 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET
 SYS2.MCDS
0IDC3014I CATALOG ERROR
 IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS
 IDC3009I IGG0CLEV-110
1IDCAMS  SYSTEM SERVICES   TIME: 
19:20:13    04/02/12 PAGE  2
0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

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

Re: Origins of numeric assignation of z196 & z114

[Hal Merritt]

 You answered your own question. 'Marketing names' are perceived to 'sound much 
better than...'  by marketing types. 

The names may or may not reflect anything technical. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
R.S.
Sent: Monday, April 16, 2012 9:42 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Origins of numeric assignation of z196 & z114

..snip


BTW: I really can't understand "marketing names" like z196, TS1140, or 
DS8000. Why don't they use names like Jaguar (ok, it's partially used), 
MAGSTAR, T-REX, MtBlanc or Cindy Crawford?

Last, bit not least: Athlon, or Pentium sounds much better than CMOS 11S.


--
Radoslaw Skorupka
Lodz, Poland









--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorised to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive. 

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 168.410.984 zotych.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[Mark Zelden]

On Mon, 16 Apr 2012 18:38:22 -0500, Paul Gilmartin  wrote:

>On Mon, 16 Apr 2012 17:29:23 -0600, Jerry Whitteridge wrote:
>
>>Has anyone tried (apart from Paul G) exporting the PDSE via NFS and mounting 
>>it at a z/Unix mountpoint on the same system ? That should be able to provide 
>>your path as well a classic access
>>
>We tried and failed.  But we didn't try very hard because I
>couldn't justify expending much systems programmer resource
>on my largely experimental need.  We have legacy data sets
>exported and mounted on Solaris mountpoints.  We have
>Solaris filesystems exported and mounted on z/OS.  If I need
>something in both places, I keep it on a Solaris server.
>
>John M. may have tried; I don't know with what degree of success.
>

I hadn't done it with a PDSE, but I had with a PDS.   I just tried it and it 
works 
the same.  :-)

I ran an exec similar to this from TSO to mount the PDSE on the local system:

/* rexx */
Address TSO   
 "MOUNT FILESYSTEM(NFS_ZELD) TYPE(NFS)" , 
 "MOUNTPOINT('/u/zelden/testnfs') " , 
 "PARM('SYST:""ZELDEN.TEST.PDSE,text"",xlat(Y)') " 


You can change "ZELDEN.TEST.PDSE"  to "ZELDEN.TEST" in the mount parm, then all 
my data sets 
starting ZELDEN.TEST are mounted under /u/zelden/testnfs/  and the PDSE members 
fall under
/u/zelden/testnfs/PDSE/*.


My export looks like this, so I can write to that PDSE as well:

ZELDEN-access=SYST|SYSX,rw=SYST|SYSX


Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: Origins of numeric assignation of z196 & z114

[R.S.]

W dniu 2012-04-17 16:30, Mike Schwab pisze:

On Tue, Apr 17, 2012 at 5:50 AM, Jan MOEYERSONS
  wrote:

On Mon, 16 Apr 2012 16:41:51 +0200, R.S.  wrote:


BTW: I really can't understand "marketing names" like z196, TS1140, or
DS8000. Why don't they use names like Jaguar (ok, it's partially used),
MAGSTAR, T-REX, MtBlanc or Cindy Crawford?


A rose, by any other name...


Bet he does not like BMW model names either.


No, I don't like. ;-) But you are talking about model NUMBER, not name.
The name - let's take Rolls-Royce, Audi, Mercedes, sounds IMHO better 
than z196. z196 plays the role of NAME, not model number. The m/t is 
2817. What is Quattro? It's a model of Audi. What is Silver Spirit? It's 
a model of R-R. What's 2817 it m/t of z196...
Believe me: my car do have Product Number, I'm pretty sure it's user 
unfriendly and hard to remember, ...but I don't care. We use *names*, 
like Toyota Corolla, VW Golf, Ford Mondeo.
I have never heard someone saying: I'm using Ford product 2817-M15 known 
as z196...



BTW: Let's leave it. My primary goal was to explain the meaning of 196 
and 114 and I did it. The rest is my humble opinion. I wish I would 
start Cindy or logon to Jennifer... ;-)


Regards
--
Radoslaw Skorupka
Lodz, Poland


--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

Re: ADR938E - PROBLEM WITH FASTREPLICATION

[John Dawes]

Rex,
 
My apologies, I truncated the message.  Here it is in its entirety:
 
ADR006I (052)-STEND(01), 2012.106 08:41:32 EXECUTION BEGINS 
ADR918I (052)-DDTFP(01), FAST REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1, 
RETURN CODE 1   
ADR938E (052)-DDTFP(01), FASTREPLICATION(REQUIRED) WAS SPECIFIED BUT FAST 
REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1  
ADR006I (052)-STEND(02), 2012.106 08:41:32 EXECUTION ENDS   
ADR013I (052)-CLTSK(01), 2012.106 08:41:32 TASK COMPLETED WITH RETURN CODE 0008 




From: "Pommier, Rex R." 
To: IBM-MAIN@bama.ua.edu 
Sent: Monday, 16 April 2012 2:10 PM
Subject: Re: ADR938E - PROBLEM WITH FASTREPLICATION

Is that all you got?  The messages manual says that there should have been a 
reason code with the ADR918I message.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
John Dawes
Sent: Saturday, April 14, 2012 6:18 PM
To: IBM-MAIN@bama.ua.edu
Subject: ADR938E - PROBLEM WITH FASTREPLICATION

G'Day,

I am trying to figure out this problem.  I checked the error message but I was 
unable to figure out what I should do or why the problem occurred.

ADR918I (052)-DDTFP(01), FAST REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1
ADR938E (052)-DDTFP(01), FASTREPLICATION(REQUIRED) WAS SPECIFIED BUT FAST 
REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1
ADR006I (052)-STEND(02), 2012.105 02:34:11 EXECUTION ENDS

Below is my jcl:

//STEP1    EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440
//SYSPRINT  DD  SYSOUT=*
//SYSIN    DD  *
COPY FULL INDYNAM(RXTRS1) OUTDYNAM(@@883C) ALLE ALLD(*) -
FASTREPLICATION(REQUIRED) FCNOCOPY DUMPCONDITIONING ADMIN PURGE

Any suggestions?


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

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

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

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

Re: Detail SMF record processing

[William Richardson]

Not much to tell you here .. SMF(e)WTM invokes a process which does some 
initial validation of the input and environment and then reads an in-storeage 
table to see if the record type(/subtype) has been requested by the user (via 
the parms in SMFPRMxx) and then, IF the record type was requested based on the 
parms,  the processing invokes the appropriate IEFU8x exit (based on the 
current environment).

If the record selection exit (IEFU8x) confirms the selection, the processing 
copies the input record data into a buffer in the SMF address space (cross 
memory) and signals the totally asynchronous writer function to output the 
record buffer to either the active MANx dataset -or- to the logstream which 
ever is specified in the SMFPRMxx parmlib member.

After the copy of the data noted above the SMF(e)WTM invoked processing returns 
control to the invoker of the macro (at the next instruction).
 
That's all there.

Bill..

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

Re: ADR938E - PROBLEM WITH FASTREPLICATION

[John Dawes]

Gerhard,
 
No, both volumes are on the same controller.  I found that the target address 
was a 3390-9 instead of 3390-27.  The error message is very misleading.
 
Thanks.



From: Gerhard Weisshaar 
To: IBM-MAIN@bama.ua.edu 
Sent: Monday, 16 April 2012 3:20 PM
Subject: Re: ADR938E - PROBLEM WITH FASTREPLICATION

Are the two volumes RXTRS1 and @@883C part of the same SFI (the same 
DASD "box")? If not, then FlashCopy cannot be used for the requested 
operation.

Gerhard

Am 16.04.2012 20:10, schrieb Pommier, Rex R.:
> Is that all you got?  The messages manual says that there should have been a 
> reason code with the ADR918I message.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of John Dawes
> Sent: Saturday, April 14, 2012 6:18 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: ADR938E - PROBLEM WITH FASTREPLICATION
>
> G'Day,
>
> I am trying to figure out this problem.  I checked the error message but I 
> was unable to figure out what I should do or why the problem occurred.
>
> ADR918I (052)-DDTFP(01), FAST REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1
> ADR938E (052)-DDTFP(01), FASTREPLICATION(REQUIRED) WAS SPECIFIED BUT FAST 
> REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1
> ADR006I (052)-STEND(02), 2012.105 02:34:11 EXECUTION ENDS
>
> Below is my jcl:
>
> //STEP1    EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440
> //SYSPRINT  DD  SYSOUT=*
> //SYSIN    DD  *
> COPY FULL INDYNAM(RXTRS1) OUTDYNAM(@@883C) ALLE ALLD(*) -
> FASTREPLICATION(REQUIRED) FCNOCOPY DUMPCONDITIONING ADMIN PURGE
>
> Any suggestions?
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> The information contained in this e-mail may contain confidential and/or 
> privileged information and is intended for the sole use of the intended 
> recipient. If you are not the intended recipient, you are hereby notified 
> that any unauthorized use, disclosure, distribution or copying of this 
> communication is strictly prohibited and that you will be held responsible 
> for any such unauthorized activity, including liability for any resulting 
> damages. As appropriate, such incident(s) may also be reported to law 
> enforcement. If you received this e-mail in error, please reply to sender and 
> destroy or delete the message and any attachments. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: Dynamic LPA module use count- who's using the module ?

[Peter Relson]

>Does anyone know if there is a way of finding out which address spaces 
>are using these previous versions with the non-zero use counts ?

Brute force: you could schedule an SRB to every address space and,
for every task in that address space, with appropriate serialization, run
the TCBLLS queue looking for LLE's that point to LPA CDE's (or LPDE's if
that is of interest) with an entry point that matches what you care
about.

Also, keep in mind that use counts for LPA modules (whether dynamic or 
not)
provide no information about whether the module is actually in use, they
only track the number of LOADs vs DELETEs (approximately).

Peter Relson
z/OS Core Technology Design

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

Re: GO TO "cobol"

[Scott Ford]

Yes sir, for many years, large systems CE ...


Scott Ford
Senior Systems Engineer
www.identityforge.com



On Apr 17, 2012, at 10:07 AM, Lloyd Fuller  wrote:

> Probably at the Army Finance Center there.  I think that they used Unisys.
> 
> Lloyd
> 
> 
> 
> - Original Message 
> From: Scott Ford 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tue, April 17, 2012 9:36:59 AM
> Subject: Re: GO TO "cobol"
> 
> Lloyd,
> 
> My father was a Unisys CE at the Fort for many years...
> 
> 
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
> 
> 
> 
> On Apr 17, 2012, at 8:17 AM, Lloyd Fuller  wrote:
> 
>> In 1969, and until sometime in the 1970s or later, the Army programming 
>> school 
> 
>> was at Fort Benjamin Harrison in Indiana.
>> 
>> 
>> Graduated in March 1969 as a Staff Sergeant converted to a SP6.  Programming 
>> since then.
>> 
>> lLOYD
>> 
>> 
>> 
>> - Original Message 
>> From: Ed Gould 
>> To: IBM-MAIN@bama.ua.edu
>> Sent: Tue, April 17, 2012 12:16:33 AM
>> Subject: Re: GO TO "cobol"
>> 
>> On Apr 16, 2012, at 8:34 AM, McKown, John wrote:
>>> SNIP-
>>> Also remember that COBOL, at least originally, was supposed to be very 
>>> English-like and so usable by people at the Army PFC level of training.
>>> 
>>> --John McKown
>>> Systems Engineer IV
>>> IT
>> 
>> Hmmm... I was in the Army and we got PFC's from the programming school (AZ? 
>> its 
>> 
>> been 40 years so forgive me). We had two groups, one COBOL (batch 
>> processing) 
>> and one ASM group (essentially sysprogs). The ASM group was by far the best 
>> IMO. 
>> 
>> I was on call quite often and had to "fix" the cobol programs that went boom 
>> in 
>> 
>> the middle of the night. The COBOL people were semi useless in debugging and 
>> when I looked at the code they had produced (except for a few people) it was 
>> hopeless to understand. I spent more time trying to figure out the logic and 
>> compare what I was seeing in the dump. 1/3 the time I helped the programmer 
>> figure out where his problem was and supplying answers to his questions on 
>> what 
>> 
>> was in this field or that field.
>> What was interesting was that as the guys (no female programmers so don't 
>> call 
> 
>> me sexist blame the Army not me) as they became more experienced the code 
>> became 
>> 
>> easier to follow. As they became became better programmers there were less 
>> logic 
>> 
>> problems. Now having said that most of the programs were  smallish and only 
>> a 
>> few were considered large so the smallish programs there was no excuse for 
>> logic 
>> 
>> issues or mangled code. My memory is foggy here as to goto's but I think the 
>> "rule" no standards if memory serves me that goto's were to be minimized as 
>> a 
>> result flow was easier to follow and frankly debugging was easier.
>> 
>> Ed
>> 
>> ps: We had one person who at the time he was drafted was working for IBM and 
>> he 
>> 
>> privately told me about some OS enhancements that when I first heard I 
>> couldn't 
>> 
>> wrap my head around as virtual (at least that I had never heard of) was a 
>> nightmare that I couldn't wrap my head around. After I got out of the Army 
>> (2 
>> years) IBM announced Virtual and I was able to ask some semi intelligent 
>> questions as my "preview" and the questions helped jump start by job.
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: GO TO "cobol"

[Lloyd Fuller]

Probably at the Army Finance Center there.  I think that they used Unisys.

Lloyd



- Original Message 
From: Scott Ford 
To: IBM-MAIN@bama.ua.edu
Sent: Tue, April 17, 2012 9:36:59 AM
Subject: Re: GO TO "cobol"

Lloyd,

My father was a Unisys CE at the Fort for many years...


Scott Ford
Senior Systems Engineer
www.identityforge.com



On Apr 17, 2012, at 8:17 AM, Lloyd Fuller  wrote:

> In 1969, and until sometime in the 1970s or later, the Army programming 
> school 

> was at Fort Benjamin Harrison in Indiana.
> 
> 
> Graduated in March 1969 as a Staff Sergeant converted to a SP6.  Programming 
> since then.
> 
> lLOYD
> 
> 
> 
> - Original Message 
> From: Ed Gould 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tue, April 17, 2012 12:16:33 AM
> Subject: Re: GO TO "cobol"
> 
> On Apr 16, 2012, at 8:34 AM, McKown, John wrote:
>> SNIP-
>> Also remember that COBOL, at least originally, was supposed to be very 
>> English-like and so usable by people at the Army PFC level of training.
>> 
>> --John McKown
>> Systems Engineer IV
>> IT
> 
> Hmmm... I was in the Army and we got PFC's from the programming school (AZ? 
> its 
>
> been 40 years so forgive me). We had two groups, one COBOL (batch processing) 
> and one ASM group (essentially sysprogs). The ASM group was by far the best 
>IMO. 
>
> I was on call quite often and had to "fix" the cobol programs that went boom 
> in 
>
> the middle of the night. The COBOL people were semi useless in debugging and 
> when I looked at the code they had produced (except for a few people) it was 
> hopeless to understand. I spent more time trying to figure out the logic and 
> compare what I was seeing in the dump. 1/3 the time I helped the programmer 
> figure out where his problem was and supplying answers to his questions on 
> what 
>
> was in this field or that field.
> What was interesting was that as the guys (no female programmers so don't 
> call 

> me sexist blame the Army not me) as they became more experienced the code 
>became 
>
> easier to follow. As they became became better programmers there were less 
>logic 
>
> problems. Now having said that most of the programs were  smallish and only a 
> few were considered large so the smallish programs there was no excuse for 
>logic 
>
> issues or mangled code. My memory is foggy here as to goto's but I think the 
> "rule" no standards if memory serves me that goto's were to be minimized as a 
> result flow was easier to follow and frankly debugging was easier.
> 
> Ed
> 
> ps: We had one person who at the time he was drafted was working for IBM and 
> he 
>
> privately told me about some OS enhancements that when I first heard I 
> couldn't 
>
> wrap my head around as virtual (at least that I had never heard of) was a 
> nightmare that I couldn't wrap my head around. After I got out of the Army (2 
> years) IBM announced Virtual and I was able to ask some semi intelligent 
> questions as my "preview" and the questions helped jump start by job.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Origins of numeric assignation of z196 & z114

[Mike Schwab]

On Tue, Apr 17, 2012 at 5:50 AM, Jan MOEYERSONS
 wrote:
> On Mon, 16 Apr 2012 16:41:51 +0200, R.S.  
> wrote:
>
>>BTW: I really can't understand "marketing names" like z196, TS1140, or
>>DS8000. Why don't they use names like Jaguar (ok, it's partially used),
>>MAGSTAR, T-REX, MtBlanc or Cindy Crawford?
>
> A rose, by any other name...
>
Bet he does not like BMW model names either.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Modernizing the BCP code ?

[Shmuel Metz (Seymour J.)]

In
,
on 04/13/2012
   at 09:23 AM, Kirk Wolf  said:

>With the explosion of new instructions, at what point does writing
>hand-written assembler code become less and less practical?

I would have thought that it was the other way around; with the
explosion of specialized instructions, assembler code that explots
them is more high level than what we were writing a few decades ago.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Scott Ford]

Lloyd,

My father was a Unisys CE at the Fort for many years...


Scott Ford
Senior Systems Engineer
www.identityforge.com



On Apr 17, 2012, at 8:17 AM, Lloyd Fuller  wrote:

> In 1969, and until sometime in the 1970s or later, the Army programming 
> school 
> was at Fort Benjamin Harrison in Indiana.
> 
> 
> Graduated in March 1969 as a Staff Sergeant converted to a SP6.  Programming 
> since then.
> 
> lLOYD
> 
> 
> 
> - Original Message 
> From: Ed Gould 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tue, April 17, 2012 12:16:33 AM
> Subject: Re: GO TO "cobol"
> 
> On Apr 16, 2012, at 8:34 AM, McKown, John wrote:
>> SNIP-
>> Also remember that COBOL, at least originally, was supposed to be very 
>> English-like and so usable by people at the Army PFC level of training.
>> 
>> --John McKown
>> Systems Engineer IV
>> IT
> 
> Hmmm... I was in the Army and we got PFC's from the programming school (AZ? 
> its 
> been 40 years so forgive me). We had two groups, one COBOL (batch processing) 
> and one ASM group (essentially sysprogs). The ASM group was by far the best 
> IMO. 
> I was on call quite often and had to "fix" the cobol programs that went boom 
> in 
> the middle of the night. The COBOL people were semi useless in debugging and 
> when I looked at the code they had produced (except for a few people) it was 
> hopeless to understand. I spent more time trying to figure out the logic and 
> compare what I was seeing in the dump. 1/3 the time I helped the programmer 
> figure out where his problem was and supplying answers to his questions on 
> what 
> was in this field or that field.
> What was interesting was that as the guys (no female programmers so don't 
> call 
> me sexist blame the Army not me) as they became more experienced the code 
> became 
> easier to follow. As they became became better programmers there were less 
> logic 
> problems. Now having said that most of the programs were  smallish and only a 
> few were considered large so the smallish programs there was no excuse for 
> logic 
> issues or mangled code. My memory is foggy here as to goto's but I think the 
> "rule" no standards if memory serves me that goto's were to be minimized as a 
> result flow was easier to follow and frankly debugging was easier.
> 
> Ed
> 
> ps: We had one person who at the time he was drafted was working for IBM and 
> he 
> privately told me about some OS enhancements that when I first heard I 
> couldn't 
> wrap my head around as virtual (at least that I had never heard of) was a 
> nightmare that I couldn't wrap my head around. After I got out of the Army (2 
> years) IBM announced Virtual and I was able to ask some semi intelligent 
> questions as my "preview" and the questions helped jump start by job.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: GO TO "cobol"

[Scott Ford]

Whatever happened to everyone talking about structured COBOL code.
I usually perform paragraph- name thru paragraph- name exit. I but agree flow 
logic in COBOL need revision. Especially, when you in the middle of the 
perform. Using 'continue' to good, but sometimes deadlines force you to write 
not the way you want too


Scott Ford
Senior Systems Engineer
www.identityforge.com



On Apr 17, 2012, at 9:12 AM, Jeff Holst  wrote:

> Without the GO TO, Grace Hopper might have been forever stuck in Japan.
> 
> Many years ago, I was at an ACM meeting where Grace Hopper was a speaker. One 
> of the stories she told was of a visit to a data center in Japan. Somehow, 
> she was left there without an interpretter. The folks at the data center 
> spoke no English and she spoke no Japanese. Fortunately, the programmers knew 
> COBOL. And while COBOL was designed so that the english commands could be 
> easily translated into other languages (in most languages, the verb in a 
> command is the first thing in the sentence), this is almost never done. Her 
> solution was simple. She poiinted at herself, then said GO TO and the name of 
> the hotel. This was enoungh so that the programmers were able to get her to 
> the hotel.
> 
> Jeff Holst 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: GO TO "cobol"

[Jeff Holst]

Without the GO TO, Grace Hopper might have been forever stuck in Japan.

Many years ago, I was at an ACM meeting where Grace Hopper was a speaker. One 
of the stories she told was of a visit to a data center in Japan. Somehow, she 
was left there without an interpretter. The folks at the data center spoke no 
English and she spoke no Japanese. Fortunately, the programmers knew COBOL. And 
while COBOL was designed so that the english commands could be easily 
translated into other languages (in most languages, the verb in a command is 
the first thing in the sentence), this is almost never done. Her solution was 
simple. She poiinted at herself, then said GO TO and the name of the hotel. 
This was enoungh so that the programmers were able to get her to the hotel.

Jeff Holst 

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

Re: z/OS every two years (Official announcment)

[Kurt Quackenbush]

...  I don't know about
FTPS or SFTP (variant of ssh).  Can someone suggest a publicly
accessible site(s) I can experiment with?


testcase.boulder.ibm.com supports FTPS.

Kurt Quackenbush -- IBM, SMP/E Development

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

Re: GO TO "cobol"

[Patrick Roehl]

This is true, but I prefer to use the "end" constructs because they are
safer.  The safety comes from the compiler complaining about IF and END-Ifs
not matching.  An errant period generates no such indicator and causes a
bug.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Matthew Stitt
Sent: Monday, April 16, 2012 5:45 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: GO TO "cobol"

If some-test-here-failed
 Set indicator-switch to true
 Go to 2000-exit
 End-if.

 If some-other-test-fails
 Set indicator-different-switch to true
 Go to 2000-exit
 End-if.

---

You could have the exact same result by placing a period after the
"2000-exit".  Then the End-if is not needed.



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

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[McKown, John]

Thanks. It's reassuring that I'm no stupider than usual.

I don't have PL/I, but from looking at the manual, it seems to suffer from the 
same problem.
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ibm3pg80/1.4.1.4

And FORTRAN doesn't even seem to support any z/OS UNIX usage at all. There is 
nothing in the books.

-- 
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@bama.ua.edu] On Behalf Of Steve Comstock
> Sent: Monday, April 16, 2012 5:21 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Anybody use the "cob2" command on a UNIX shell 
> to compile COBOL?
> 
> On 4/16/2012 3:26 PM, McKown, John wrote:
> > If so, have you figured out how to specify a PDS as an "include" or
> > "copybook"source? The documentation for this command 
> basically stinks.
> 
> > There is an -I switch. But it apparently only accepts UNIX 
> path specifications.
> > The ld command (binder) accepts a PDS name via -L 
> "//pds.name". The as command
> > (HLASM) and C compilers accept a -I "//pds.name". I may end 
> up writing my own
> > version of the "cob2" command, if I really decide that I 
> want to compile COBOL
> > from the UNIX shell. I'll likely model it after the as command.
> 
> Yes. I discuss this command in our course "Developing Applications for
> z/OS UNIX". But you're right, the doc is very poor. The 
> assumption seems
> to be that copy books must be in HFS directories and my experiments
> produce error messages that would support that.
> 
> In a way, that's too bad. OTOH, I, too, was assuming that copy books
> would reside in HFS directories so I had never tried to access copy
> books as members of a PDS before.
> 
> You would think that if you used the classic clue that a library was
> a PDS/E, the compiler could figure it out. Maybe:
> 
> export SYSLIB="//'SCOMSTO.U520.LIBRARY'"
> 
> which I tried, and the message from the compile comes back:
> 
>   LineID  Message code  Library phase message text
>   24  IGYLI0049-S   The "COPY" library 
> "SCOMSTO.U520.LIBRARY/APODEFS" was not
> found.  Skipped to the period 
> terminating the "COPY"
> statement.
> 
> so it was pretty clearly expecting (nay: requiring) a z/OS UNIX
> file, not a PDS.
> 
> I'm copying this over to ibm-main, too, as Tom Ross occasionally
> follows that group so maybe he will chime in with some info.
> 
> 
> 
> > 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
> >
> >
> > 
> --
> > For MVS-OE subscribe / signoff / archive access instructions,
> > send email to lists...@vm.marist.edu with the message: INFO MVS-OE
> >
> 
> 
> -- 
> 
> Kind regards,
> 
> -Steve Comstock
> The Trainer's Friend, Inc.
> 
> 303-355-2752
> http://www.trainersfriend.com
> 
> * To get a good Return on your Investment, first make an investment!
>+ Training your people is an excellent investment
> 
> * Try our tool for calculating your Return On Investment
>  for training dollars at
>http://www.trainersfriend.com/ROI/roi.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

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

Re: GO TO "cobol"

[Lloyd Fuller]

In 1969, and until sometime in the 1970s or later, the Army programming school 
was at Fort Benjamin Harrison in Indiana.


Graduated in March 1969 as a Staff Sergeant converted to a SP6.  Programming 
since then.

lLOYD



- Original Message 
From: Ed Gould 
To: IBM-MAIN@bama.ua.edu
Sent: Tue, April 17, 2012 12:16:33 AM
Subject: Re: GO TO "cobol"

On Apr 16, 2012, at 8:34 AM, McKown, John wrote:
> SNIP-
> Also remember that COBOL, at least originally, was supposed to be very 
>English-like and so usable by people at the Army PFC level of training.
> 
> --John McKown
> Systems Engineer IV
> IT

Hmmm... I was in the Army and we got PFC's from the programming school (AZ? its 
been 40 years so forgive me). We had two groups, one COBOL (batch processing) 
and one ASM group (essentially sysprogs). The ASM group was by far the best 
IMO. 
I was on call quite often and had to "fix" the cobol programs that went boom in 
the middle of the night. The COBOL people were semi useless in debugging and 
when I looked at the code they had produced (except for a few people) it was 
hopeless to understand. I spent more time trying to figure out the logic and 
compare what I was seeing in the dump. 1/3 the time I helped the programmer 
figure out where his problem was and supplying answers to his questions on what 
was in this field or that field.
What was interesting was that as the guys (no female programmers so don't call 
me sexist blame the Army not me) as they became more experienced the code 
became 
easier to follow. As they became became better programmers there were less 
logic 
problems. Now having said that most of the programs were  smallish and only a 
few were considered large so the smallish programs there was no excuse for 
logic 
issues or mangled code. My memory is foggy here as to goto's but I think the 
"rule" no standards if memory serves me that goto's were to be minimized as a 
result flow was easier to follow and frankly debugging was easier.

Ed

ps: We had one person who at the time he was drafted was working for IBM and he 
privately told me about some OS enhancements that when I first heard I couldn't 
wrap my head around as virtual (at least that I had never heard of) was a 
nightmare that I couldn't wrap my head around. After I got out of the Army (2 
years) IBM announced Virtual and I was able to ask some semi intelligent 
questions as my "preview" and the questions helped jump start by job.

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

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

Re: GO TO "cobol"

[Lloyd Fuller]

PFC = Private First Class.  An Army rank.  The Marines may also use it.


Lloyd


- Original Message 
From: Paul Gilmartin 
To: IBM-MAIN@bama.ua.edu
Sent: Mon, April 16, 2012 7:27:30 PM
Subject: Re: GO TO "cobol"

On Mon, 16 Apr 2012 16:45:21 -0500, Matthew Stitt wrote:
>
>You could have the exact same result by placing a period
>after the "2000-exit".  Then the End-if is not needed.
>
>
> 
I sure am glad that COBOL attained its design objective
of being intelligible (intuitively? unambiguously?) to a
PFC-level programmer with only an understanding of
vernacular English.

(Is "PFC" a Navy rank?)

-- gil

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

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

Re: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[McKown, John]

I've tried, but I seem to have a mental block on getting the NFS server working 
on z/OS. I use the client to a Linux server with no problem.

--
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@bama.ua.edu] On Behalf Of Jerry Whitteridge
> Sent: Monday, April 16, 2012 6:29 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Anybody use the "cob2" command on a UNIX shell 
> to compile COBOL?
> 
> Has anyone tried (apart from Paul G) exporting the PDSE via 
> NFS and mounting it at a z/Unix mountpoint on the same system 
> ? That should be able to provide your path as well a classic access  
> 
> Jerry Whitteridge
> Lead Systems Programmer
> Safeway Inc.
> 925 951 4184
> 
> If you feel in control
> you just aren't going fast enough.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Steve Comstock
> Sent: Monday, April 16, 2012 3:21 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Anybody use the "cob2" command on a UNIX shell 
> to compile COBOL?
> 
> On 4/16/2012 3:26 PM, McKown, John wrote:
> > If so, have you figured out how to specify a PDS as an "include" or
> > "copybook"source? The documentation for this command 
> basically stinks.
> 
> > There is an -I switch. But it apparently only accepts UNIX path
> specifications.
> > The ld command (binder) accepts a PDS name via -L 
> "//pds.name". The as
> command
> > (HLASM) and C compilers accept a -I "//pds.name". I may end 
> up writing
> my own
> > version of the "cob2" command, if I really decide that I 
> want to compile
> COBOL
> > from the UNIX shell. I'll likely model it after the as command.
> 
> Yes. I discuss this command in our course "Developing Applications for
> z/OS UNIX". But you're right, the doc is very poor. The 
> assumption seems
> to be that copy books must be in HFS directories and my experiments
> produce error messages that would support that.
> 
> In a way, that's too bad. OTOH, I, too, was assuming that copy books
> would reside in HFS directories so I had never tried to access copy
> books as members of a PDS before.
> 
> You would think that if you used the classic clue that a library was
> a PDS/E, the compiler could figure it out. Maybe:
> 
> export SYSLIB="//'SCOMSTO.U520.LIBRARY'"
> 
> which I tried, and the message from the compile comes back:
> 
>   LineID  Message code  Library phase message text
>   24  IGYLI0049-S   The "COPY" library 
> "SCOMSTO.U520.LIBRARY/APODEFS"
> was not
> found.  Skipped to the period terminating the
> "COPY"
> statement.
> 
> so it was pretty clearly expecting (nay: requiring) a z/OS UNIX
> file, not a PDS.
> 
> I'm copying this over to ibm-main, too, as Tom Ross occasionally
> follows that group so maybe he will chime in with some info.
> 
> 
> 
> > 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
> >
> >
> > 
> --
> > For MVS-OE subscribe / signoff / archive access instructions,
> > send email to lists...@vm.marist.edu with the message: INFO MVS-OE
> >
> 
> 
> -- 
> 
> Kind regards,
> 
> -Steve Comstock
> The Trainer's Friend, Inc.
> 
> 303-355-2752
> http://www.trainersfriend.com
> 
> * To get a good Return on your Investment, first make an investment!
>+ Training your people is an excellent investment
> 
> * Try our tool for calculating your Return On Investment
>  for training dollars at
>http://www.trainersfriend.com/ROI/roi.html
> 
> 

Re: GO TO "cobol"

[McKown, John]

Only if you consider a Marine to be in the Navy (Technically, they are under 
the department of the Navy). But you'll do that only if you don't mind losing 
some teeth. 

-- 
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@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Monday, April 16, 2012 6:27 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: GO TO "cobol"
> 
> On Mon, 16 Apr 2012 16:45:21 -0500, Matthew Stitt wrote:
> >
> >You could have the exact same result by placing a period
> >after the "2000-exit".  Then the End-if is not needed.
> >
> >
> > 
> I sure am glad that COBOL attained its design objective
> of being intelligible (intuitively? unambiguously?) to a
> PFC-level programmer with only an understanding of
> vernacular English.
> 
> (Is "PFC" a Navy rank?)
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

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

Re: IEHLIST LISTVTOC inconsistency

[Veilleux, Jon L]

Do you have any specifics? What difference are you seeing? What kind of volume? 
Etc.
I would like to test on our systems
Thanks,
Jon

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
John Eells
Sent: Tuesday, April 17, 2012 7:25 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEHLIST LISTVTOC inconsistency

Please open a PMR.

Gord Tomlin wrote:
> I just ran into a situation where IEHLIST is providing different 
> results for the same volume depending upon whether it is run from a 
> z/OS 1.11 system or a z/OS 1.13 system.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

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

Re: IEHLIST LISTVTOC inconsistency

[John Eells]

Please open a PMR.

Gord Tomlin wrote:

I just ran into a situation where IEHLIST is providing different results
for the same volume depending upon whether it is run from a z/OS 1.11
system or a z/OS 1.13 system.



--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Origins of numeric assignation of z196 & z114

[Elardus Engelbrecht]

Jan MOEYERSONS wrote:

>>BTW: I really can't understand "marketing names" like z196, TS1140, or
>>DS8000. Why don't they use names like Jaguar (ok, it's partially used),
>>MAGSTAR, T-REX, MtBlanc or Cindy Crawford?

>A rose, by any other name...

Begin with dinousaurus names ( :-D ), then reptile names, then bird names, aloe 
names, etc. ;-D

Or start with a series, like this example: 8088, 8086, 80286, 80386, 80486, etc.

Or use the big 5, for example in  

http://www.resbank.co.za/AboutUs/PublicAwareness/Documents/A5%20all%20banknotes%20poster.pdf

where all of the big 5 are shown on our country's banknotes.

I like names for products if they are in a series or a group. Easier for 
marketing blurbs in airline magazines...

:-D

Groete / Greetings
Elardus Engelbrecht

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

Re: Detail SMF record processing

[Elardus Engelbrecht]

Donald Likens wrote:

>I do not need to include the processing before doing the SMFEWTM if I am 
>attempting to determine how much processing is done after the SMFEWTM is 
>issued. Assume I have already gathered all the data and now I am  attempting 
>to determine what I should do with it.

For what SMF record type?

Do you need 'processing' for writing it out to a temporary storage, then to 
MANx datasets then to other datasets?

I'm still not sure what you mean by 'processing'? Do you mean overhead for 
post-parsing / re-formatting of the SMF record before finally writing it out to 
MANx datasets? Do you need to send this record to another exit or address space?

Or please give an example on what you're trying to accomplish, perhaps by usage 
of other SMF macros?

When using SMFEWTM, what is your intended usage of BRANCH keyword? What will 
you do if you get RC=20 upon returning from SMFEWTM?

Groete / Greetings
Elardus Engelbrecht

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

Re: Origins of numeric assignation of z196 & z114

[Jan MOEYERSONS]

On Mon, 16 Apr 2012 16:41:51 +0200, R.S.  wrote:

>BTW: I really can't understand "marketing names" like z196, TS1140, or
>DS8000. Why don't they use names like Jaguar (ok, it's partially used),
>MAGSTAR, T-REX, MtBlanc or Cindy Crawford?

A rose, by any other name...

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

Re: IEL1CL not found

[jagadishan perumal]

Hi All,

Just checked the Link :
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ibm3mg80/4.1.6.3?ACTION=MATCHES&REQUEST=ISPF&TYPE=FUZZY&SHELF=ibmsh380.bks&DT=20091013110934&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT

Which says "

There is no support for compilations under TSO

This means that the *ISPF* 4.5 option is useless with Enterprise PL/I.
You should
probably disable this option or use it for another purpose.

However, you can invoke the compiler under z/OS UNIX using the *pli* command.
For more information on using the compiler under z/OS UNIX, see the
Enterprise PL/I for z/OS Programming Guide."

Jags
On Tue, Apr 17, 2012 at 10:49 AM, Anthony Thompson <
anthony.thomp...@nt.gov.au> wrote:

> Looks like your ISPF environment is not set up properly, can't find that
> REXX. Missing a SYSPROC/SYSEXEC/application-level library.
>
> Online PL/I doco can be found from here:
> http://www-01.ibm.com/software/awdtools/pli/
>
> Click on the link for the compiler you have, there are links to doco and a
> PL/I forum
>
> I don't see that manual listed for a download, nor can I see any reference
> to ISPF customization in program directories or other listed manuals. Might
> need to talk to your local IBM rep.
>
>
> Ant.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of jagadishan perumal
> Sent: Tuesday, 17 April 2012 2:22 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEL1CL not found
>
> Apology for Typo actually its "PL/I for MVS & VM Installation and
> Customization under MVS, SC26-3119"
>
> On Tue, Apr 17, 2012 at 10:21 AM, jagadishan perumal
> wrote:
>
> > Hello All,
> >
> > Looks like I need to customize the PL/I for MVS and VM. I have found
> > the manual "PL/I for MVS & VM Compiler and Run-Time Migration
> > Guide > .zos.r12.ibm3m10/ibm3m101.htm>, SC26-3118" but I am unable to open it
> > from  "
> >
> http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ceea300%2Fceea31b0183.htm
> "
> > .
> >
> > Could anyone please help in pointing to the PDF version of the above
> > document.
> >
> > Jags
> >
> > On Tue, Apr 17, 2012 at 9:56 AM, jagadishan perumal
> >  > > wrote:
> >
> >> Thanks for your email, but as a testing I tried with the ISPF option
> >> 4.5 I get the below error message when I give the Source library at
> >>
> >> " Other Partitioned or Sequential Data
> >> Set:
> >> Name . . . . . . .
> >> 'U322501.TEST.PL1(FIRSTCD)'
> >>  List ID . . .
> >> Compiler
> >>  Password  . .  2  1. OS PL/I Version 2 2. PLI for MVS
> >> and VM   "
> >>
> >>
> >> "IKJ56479I COMMAND IEL1IKJ5 NOT FOUND OR REXX IDENTIFIER IS MISSING+  :
> >> Could not find anything related to IEL1IKJ5 in google.
> >> IKJ56479I SUPPLY '/* REXX */' AS THE FIRST RECORD TO EXECUTE AS A
> >> REXX EXEC OR, FOR AN EXPLICIT EXEC, SUPPLY THE EXEC KEYWORD ON THE
> >> EXEC COMMAND ***"
> >>
> >> Jags
> >>
> >>
> >> On Tue, Apr 17, 2012 at 9:46 AM, Anthony Thompson <
> >> anthony.thomp...@nt.gov.au> wrote:
> >>
> >>> Oops, typo... DDDEF = SIBMZPRC not SIBMPRC
> >>>
> >>> Ant.
> >>>
> >>>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> >>> Behalf Of jagadishan perumal
> >>> Sent: Tuesday, 17 April 2012 12:18 PM
> >>> To: IBM-MAIN@bama.ua.edu
> >>> Subject: IEL1CL not found
> >>>
> >>> Hello All,
> >>>
> >>> Good Morning !!
> >>>
> >>> I am just trying to locate the proc IEL1CL in our newly installed
> >>> z/os
> >>> 1.13 within the libraries(SYS1.**, CPAC.**), but unfortunately I am
> >>> unable to locate the PROC for compiling PL/I programs. Whereas I
> >>> could get same proc in Z/OS 1.9 &1.8 level.
> >>>
> >>>
> >>> Could anyone please point me to the right direction.
> >>>
> >>>
> >>> Jags
> >>>
> >>> 
> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions,
> >>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >>>
> >>> 
> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions,
> >>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >>>
> >>
> >>
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the mes

Re: Detail SMF record processing

[Donald Likens]

I do not need to include the processing before doing the SMFEWTM if I am 
attempting to determine how much processing is done after the SMFEWTM is 
issued. Assume I have already gathered all the data and now I am  attempting to 
determine what I should do with it.

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