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

[Paul Gilmartin]

On Tue, 17 Apr 2012 22:23:09 -0500, John McKown wrote:

>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.
> 
When you do this, do you get sporadic ABENDs, typically 0C4?
I never get more than one per ISPF session -- after one I seem to
be immune.  And it happens only on ENDing a panel, so in a
sense it's harmless; I can endure it.  Ops probly doesn't welcome
the dumps.

-- gil

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

[Dale Miller]

Years ago, I learned my first programming language (FORTRAN) from an  
excellent book by Daniel McCracken who was justly famous for his  
excellent programming books. He was also known, (but not quite as  
well) for a mid-life crisis which involved completing a degree from a  
seminary, but never getting ordained, if my memory serves me. His  
popularity peaked around the time of the big push for structured  
programming, and I attended a discussion by him of structured  
programming. He was positive about it, but with a few caveats. I do  
remember his saying (approximately):"Pity the poor COBOL programmer  
working on the error recovery routines for Indexed-Sequential file  
handling, who finds himself 5 levels deep in nested PERFORMS, and is  
heard to shout as he sinks beneath the waves: 'Just one GO TO!'.".
Looking at the situation where there are multiple conditions under  
which a procedure/block should terminate, if one is forced to follow  
the stricture of a single exit from a procedure, one is forced to  
choose between a convoluted set of nested if's or using goto's to the  
single exit point. The use of goto's could be considerably easier to  
follow, especially in the case of the original non-structured COBOL  
where PERFORM's would be necessary.


Dale Miller

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

Mark,

"If you use that exec to "undo" indirect cataloging, *YOU MUST* change
"DEVT()"  to "DEVT(3390)"   (assuming you are not using something
like a P/390 with 3380 DASD) before submitting the IDCAMS job"

Yeah I have pointed DEVT(3390)..

On Wed, Apr 18, 2012 at 8:30 PM, Tom Marchant wrote:

> On Wed, 18 Apr 2012 08:18:25 +0530, Jake anderson wrote:
>
> >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.
>
> Are you sure you want to do that?
>
> Why?
>
> There might be a better solution to whatever problem you are trying to
> solve.
>
> --
> Tom Marchant
>
> --
> 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"

[Paul Gilmartin]

On Wed, 18 Apr 2012 21:59:33 -0300, Clark Morris wrote:

>On Wed, 18 Apr 2012 23:04:51 +0200 (CEST), in bit.listserv.ibm-main
>Nomen Nescio wrote:
> 
Hoo dat!?

>>This gets back to what I said. PERFORM is net 5 instructions more *per PEFORM*
>>than two GO TOs (to and fro) so loops processing millions of records get very
>>expensive fast and avoiding GO TO by being forced to use PERFORM causes you
>>to create more loops  ...
>
I'm just sitting here trying to imagine what significant fraction of the
time required to "process [a] record" is 5 instructions.

-- gil

--
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 Wed, 18 Apr 2012 23:04:51 +0200 (CEST), in bit.listserv.ibm-main
Nomen Nescio wrote:

* this is a response to a posting to just the newsgroup and not the
listserv

>mathwst...@bellsouth.net (Matthew Stitt) wrote:
>
>> 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.
>
>This gets back to what I said. PERFORM is net 5 instructions more *per PEFORM*
>than two GO TOs (to and fro) so loops processing millions of records get very
>expensive fast and avoiding GO TO by being forced to use PERFORM causes you
>to create more loops than you would have used with GO TO since it changes
>the paradigm from essentially full steam ahead (straight line) to LET'S MAKE
>A LOOP! Last time I looked, COBOL doesn't inline PERFORM so you pay the
>penalty hundreds or thousands of millions (yeah billions, definitely
>billions) of times in a big program processing a big file. And paging is
>usually significantly worse because of the unnatural long branches caused by
>PERFORM, when straight line coding with careful use of GO TOs would have
>reduced paging since only errors and stuff like page breaks are handled out
>of line.

What you are saying was true with the COBOL VS (1974 standard)
compiler.  If you use OPTIMIZE AND do not reach any PERFORMed
paragraph via GO TO or fall through, with VS COBOL II V1R4 and
subsequent 390 and z compilers, the PERFORM will NOT take 5
instructions and depending on various conditions the PERFORM will be
replaced by the code of the paragraph being PERFORMed.  Having coded
many programs using ALTER switch-paragraph TO next-para GO TO
process-paragraph to save perform overhead, the change was dramatic.
The addition of inline PERFORM, the EVALUATE statement and the END-IF,
END-EVALUATE etc. statements have drastically changed the ball game.
If you are still coding COBOL for use on IBM z series boxes spend time
reading both the Language Reference and the Programmers Guide.
Understand and select the OPTIMIZE and TRUNC options that work in the
environment you are coding for and then code some programs and look at
the code generated.  Programs with large numbers of GO TO statements
will drive the optimizer crazy. 

I just wish that IBM would find it worth while to add the really
useful constructs in the 2002 standard such as USAGE BIT, bit
manipulation, EXIT PARAGRAPH and others.  However if the majority of
programmers remain actually or mentally stuck on the 1974 compiler, it
probably would be a waste of money.

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.
>
>Thanks for your post, it is what I experienced as well and not just once but
>dozens of times. In the old days this was never a question but decades later
>I fixed a lot of code by tearing out the spaghetti PERFORMS and processing
>forward in an orderly fashion. It is easier to understand and maintain and
>it works a lot better. For COBOL and assembler programmers that is. I don't
>really care what the C and Java crowd think of it and if they push me I'll
>rip out all their do whiles and fors and replace them all with GOTOs. Don't
>make me open this can!
>
>Practical experience beats the college boys every time, especially burnt-out
>duffers like Dijkstra who never sold a line of code and probably never wrote
>one either.

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

Re: Execute certain steps based on input parm

[Paul Gilmartin]

On Wed, 18 Apr 2012 12:25:06 -0500, Joel C. Ewing wrote:
>
>So does IBM change the docs to agree with the implementation (the
>cheaper solution), or do they change the code to not conflict with the
>docs (which may break existing usage)?  In any event, the existing JCL
>documentation should not be incomplete, confusing, and inconsistent with
>the implementation.  There is a lot to be said for more formal syntax
>and semantic descriptions.
> 
If they changed the code to issue a warning rather than an error
on the use of a "not intended or supported keyword" it would
break little existing usage.  Except in shops that have a coding
standard prohibiting JCL warnings.  But any shop so fastidious
would be expected also to shun use of unsupported constructs
and welcome the warning.  The worst case might involve a user
exit to fail jobs with JCL warnings.

But, yes, I'd favor changing the docs to agree with the implementation.
As you noted, the behavior of the unsupported constructs is largely
intuitive.  A conspicuous exception is:

//NAME JOB
//  IF FALSE THEN
//STEP1 EXEC PGM=IEFBR14
//STEP2 EXEC PGM=IEFBR14
//  ENDIF

... STEP1 executes; STEP2 does not execute.  How could
they design it that way?  And why, given that the JCL RM
prohibits IF before the first EXEC statement, don't they
report a JCL error here?  Of course, by its specification,
COND=(...) on the EXEC statement can never suppress
execution of the first job step.  So, in a false economy,
processing of COND may have been bypassed for the first
step.  Then processing of IF might have been placed in
the same logic branch.  Ugh!


>...  Good Lord, who invented this syntax?  So
>in the context of an "IF" statement relational expression, "=" is both a
>relational operator and also a lexical part of such key words as the
>above.  A rational person familiar with practically any other
>programming language (and with other JCL relational expressions) would
>intuitively expect given "ABENDCC=U001" as valid, for "ABENDCC = U001",
>"ABENDCC EQ U001", and "ABENDCC NE U001" to all be legal syntax, which
>they apparently are not.  It is a confusing and unnatural syntactic act
>to permit the same special symbol to serve as both an operator and as
>part of a keyword!


I hate JCL!

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

[Tony Harminc]

On 17 April 2012 21:26, Shmuel Metz (Seymour J.)
 wrote:

>>I suspect they continue to use a combination of DADSM and
>>home-grown manipulation of control blocks.
>
> More likely a bog standard search of the TIOT with some of them doing
> an OPENJ, e.g., IEHLIST, IEHPROGM.

For IEHLIST you're probably right. IEHMOVE did its own allocation (SVC
32) in pre-OCO days, and it may well still do so for all I know. Of
course the number of users of the IEH utilities has doubtless dropped
off...

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

[Shmuel Metz (Seymour J.)]

In
,
on 04/17/2012
   at 05:49 PM, Tony Harminc  said:

>I suspect they continue to use a combination of DADSM and 
>home-grown manipulation of control blocks.

More likely a bog standard search of the TIOT with some of them doing
an OPENJ, e.g., IEHLIST, IEHPROGM.
 
-- 
 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 <1334691539.94814.yahoomai...@web180906.mail.ne1.yahoo.com>, on
04/17/2012
   at 12:38 PM, Lloyd Fuller  said:

>Univac SAAL computers

ITYM UNIVAC 1005[1]. I had successfully ripped the memory out by the
roots; thank you for reminding me :-(

[1] SAAL was the assembler.
 
-- 
 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: Anybody use the "cob2" command on a UNIX shell to compile COBOL?

[Paul Gilmartin]

On Tue, 17 Apr 2012 22:23:09 -0500, John McKown wrote:

>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.
> 
Me, too.  It could even be a temp DSN; NEW,DELETE.

One drawback, though, is that DDLIST won't show members in
the USS catenand(s).  PMR submitted, years ago.  WAD.

-- gil

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

Re: JCL help (yes, with COND)

[Frank Swarbrick]

Sorry, my cut and paste went awry.  Should be this:


//EP4IN  PROC
//STEP01 EXEC PGM=IEFBR14,COND=(20,LT)
//STEP01A  EXEC PGM=IEFBR14,COND=(20,LT)
//STEP02 EXEC PGM=EPZOS,COND=(20,LT)
//STEP03   EXEC PGM=IDCAMS,COND=(7,LT)
//STEP04   EXEC PGM=EPTBLUPD
//  IF ( STEP04.RC = 3 ) THEN
//STEP05 EXEC PGM=IEBGENER,COND=((7,LT),(4,LT,STEP03),(4,LT,STEP04))
//  ENDIF
//  IF ( STEP04.RC = 0 | STEP04.RC = 4 ) THEN
//STEPLAST EXEC EPLINK99
//  ENDIF
//STEP06 EXEC PGM=IEBGENER,COND=(24,LT)
//STEP07 EXEC PGM=EPX99,COND=(20,LT)
//EP4IN  PEND


Anyway, I did totally misunderstand how COND works when executing a PROC rather 
than a PGM. Thanks!

As for mixing IF/THEN/ELSE with COND, as I said, its a vendor supplied PROC. 
Definitely don't want to mess with it.  But it looks like you're saying I can 
use IF/THEN logic to skip the EP4IN step if the BACKUP1 step fails.  So I will 
do that.
As much as I hate COND, at least it "fits" within how JCL otherwise looks, 
which is more than I can say for IF/THEN/ELSE!  Oh well!

Thanks again,
Frank





>
> From: Joel C. Ewing 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Wednesday, April 18, 2012 1:14 PM
>Subject: Re: JCL help (yes, with COND)
> 
>On 04/18/2012 12:43 PM, Frank Swarbrick wrote:
>> I have the following job (cut down to include only the relevant parts):
>>
>>
>> //VAPPROC4 JOB
>> //BACKUP1  EXEC PROC=SORTBKUP,COND=(4,LT)
>> //EP4IN    EXEC PROC=EP4IN,COND=(4,LT)
>> //E4INPRT  EXEC PROC=E4INPRT
>> //
>>
>>
>> The EP4IN PROC is a vendor supplied proc as follows:
>>
>>
>> //EP4IN  PROC
>> //STEP01 EXEC PGM=IEFBR14,COND=(20,LT)
>> //STEP01A  EXEC PGM=IEFBR14,COND=(20,LT)
>> //STEP02 EXEC PGM=EPZOS,COND=(20,LT)
>> //STEP03   EXEC PGM=IDCAMS,COND=(7,LT)
>> //STEP04   EXEC PGM=EPTBLUPD
>> //  IF ( STEP04.RC = 3 ) THEN
>> //STEP05 EXEC PGM=IEBGENER,COND=((7,LT),(4,LT,STEP03),(4,LT,STEP04))
>> //  ENDIF
>> //  IF ( STEP04.RC = 0 | STEP04.RC = 4 ) THEN
>> //STEPLAST EXEC EPLINK99
>> //  ENDIF
>> //EP4IN  PEND
>> //STEP06 EXEC PGM=IEBGENER,COND=(24,LT)
>> //STEP07 EXEC PGM=EPX99,COND=(20,LT)
>> //EP4IN  PROC
>>
>> I've already solved my issue (which I will detail below), but I'm still 
>> unclear as to why what I had was wrong, and why my fix actually fixes it.
>>
>> The issue is that EP4IN.STEP06 and EP4IN.STEP07 were not being executed:
>>
>> IEF202I VAPPROC4 STEP06 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES
>> IEF272I VAPPROC4 STEP06 EP4IN - STEP WAS NOT EXECUTED.
>>
>> IEF202I VAPPROC4 STEP07 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES
>> IEF272I VAPPROC4 STEP07 EP4IN - STEP WAS NOT EXECUTED.
>>
>> STEPNAME PROCSTEP    RC
>> BACKUP1  BACKUP      00
>> EP4IN    STEP01      00
>> EP4IN    STEP01A     00
>> EP4IN    STEP02      00
>> EP4IN    STEP03      05
>> EP4IN    STEP04   FLUSH
>> EP4IN    STEP05   FLUSH
>> STEPLAST STEP16   FLUSH
>> STEPLAST STEP17   FLUSH
>> EP4IN    STEP06   FLUSH
>> EP4IN    STEP07   FLUSH
>>
>> (It's expected that EP4IN.STEP04, EP4IN.STEP05, STEPLAST.STEP16 and 
>> STEPLAST.STEP17 do not execute under these conditions, becasue EP4IN.STEP03 
>> resulted in RC=05; they execute only when RC=03 for this step.)
>>
>> Anyway, the solution is to remove the COND parameter from the "EXEC 
>> PROC=EP4IN".
>> My new result follows:
>>
>> BACKUP1  BACKUP      00
>> EP4IN    STEP01      00
>> EP4IN    STEP01A     00
>> EP4IN    STEP02      00
>> EP4IN    STEP03      05
>> EP4IN    STEP04   FLUSH
>> EP4IN    STEP05   FLUSH
>> STEPLAST STEP16   FLUSH
>> STEPLAST STEP17   FLUSH
>> EP4IN    STEP06      00
>> EP4IN    STEP07      00
>> E4INPRT  REPORT      00
>>
>> What really was the issue and why did my solution resolve it?
>> My reason for including this parameter is so that EP4IN should be bypassed 
>> if BACKUP1 fails.
>>
>> Once again I ponder the sanity of the inventor of COND.
>>
>> Thanks,
>> Frank
>>
>
>The EP4IN PROC seems to have an embedded PEND and then a spurious PROC 
>statement at the end (where the PEND should be ?).  I suspect  the 
>problem is that combining COND on an EXEC PROC with embedded use of COND 
>inside a PROC does not interact well and seldom does what one might 
>expect/want.  The COND on the "EXEC PROC" statement does not determine 
>whether that EXEC is performed -- it instead overrides the COND 
>parameter on every EXEC within the PROC and determines when steps within 
>the PROC will be executed, completely ignoring any original carefully 
>thought out conditional logic using COND on EXECs within the PROC 
>definition itself.
>
>As a side issue, mixing IF/THEN/ELSE conditional execution with use of 
>COND is so highly confusing, we always recommended not introducing the 
>new forms without converting old EXEC COND usage to IF/THEN/ELSE 
>statements at the same time (except possibly for COND on the JOB 
>statement).  Also one can use IF/THEN/ELSE in the main JCL stream 
>without the bizarre override issues you get with COND on the "EXEC PROC".
>
>-- 
>Joel C. Ewing,    Bentonville, AR      jcew...

Re: JCL help (yes, with COND)

[Joel C. Ewing]

On 04/18/2012 12:43 PM, Frank Swarbrick wrote:

I have the following job (cut down to include only the relevant parts):


//VAPPROC4 JOB
//BACKUP1  EXEC PROC=SORTBKUP,COND=(4,LT)
//EP4INEXEC PROC=EP4IN,COND=(4,LT)
//E4INPRT  EXEC PROC=E4INPRT
//


The EP4IN PROC is a vendor supplied proc as follows:


//EP4IN  PROC
//STEP01 EXEC PGM=IEFBR14,COND=(20,LT)
//STEP01A  EXEC PGM=IEFBR14,COND=(20,LT)
//STEP02 EXEC PGM=EPZOS,COND=(20,LT)
//STEP03   EXEC PGM=IDCAMS,COND=(7,LT)
//STEP04   EXEC PGM=EPTBLUPD
//  IF ( STEP04.RC = 3 ) THEN
//STEP05 EXEC PGM=IEBGENER,COND=((7,LT),(4,LT,STEP03),(4,LT,STEP04))
//  ENDIF
//  IF ( STEP04.RC = 0 | STEP04.RC = 4 ) THEN
//STEPLAST EXEC EPLINK99
//  ENDIF
//EP4IN  PEND
//STEP06 EXEC PGM=IEBGENER,COND=(24,LT)
//STEP07 EXEC PGM=EPX99,COND=(20,LT)
//EP4IN  PROC

I've already solved my issue (which I will detail below), but I'm still unclear 
as to why what I had was wrong, and why my fix actually fixes it.

The issue is that EP4IN.STEP06 and EP4IN.STEP07 were not being executed:

IEF202I VAPPROC4 STEP06 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES
IEF272I VAPPROC4 STEP06 EP4IN - STEP WAS NOT EXECUTED.

IEF202I VAPPROC4 STEP07 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES
IEF272I VAPPROC4 STEP07 EP4IN - STEP WAS NOT EXECUTED.

STEPNAME PROCSTEPRC
BACKUP1  BACKUP  00
EP4INSTEP01  00
EP4INSTEP01A 00
EP4INSTEP02  00
EP4INSTEP03  05
EP4INSTEP04   FLUSH
EP4INSTEP05   FLUSH
STEPLAST STEP16   FLUSH
STEPLAST STEP17   FLUSH
EP4INSTEP06   FLUSH
EP4INSTEP07   FLUSH

(It's expected that EP4IN.STEP04, EP4IN.STEP05, STEPLAST.STEP16 and 
STEPLAST.STEP17 do not execute under these conditions, becasue EP4IN.STEP03 
resulted in RC=05; they execute only when RC=03 for this step.)

Anyway, the solution is to remove the COND parameter from the "EXEC PROC=EP4IN".
My new result follows:

BACKUP1  BACKUP  00
EP4INSTEP01  00
EP4INSTEP01A 00
EP4INSTEP02  00
EP4INSTEP03  05
EP4INSTEP04   FLUSH
EP4INSTEP05   FLUSH
STEPLAST STEP16   FLUSH
STEPLAST STEP17   FLUSH
EP4INSTEP06  00
EP4INSTEP07  00
E4INPRT  REPORT  00

What really was the issue and why did my solution resolve it?
My reason for including this parameter is so that EP4IN should be bypassed if 
BACKUP1 fails.

Once again I ponder the sanity of the inventor of COND.

Thanks,
Frank



The EP4IN PROC seems to have an embedded PEND and then a spurious PROC 
statement at the end (where the PEND should be ?).  I suspect  the 
problem is that combining COND on an EXEC PROC with embedded use of COND 
inside a PROC does not interact well and seldom does what one might 
expect/want.  The COND on the "EXEC PROC" statement does not determine 
whether that EXEC is performed -- it instead overrides the COND 
parameter on every EXEC within the PROC and determines when steps within 
the PROC will be executed, completely ignoring any original carefully 
thought out conditional logic using COND on EXECs within the PROC 
definition itself.


As a side issue, mixing IF/THEN/ELSE conditional execution with use of 
COND is so highly confusing, we always recommended not introducing the 
new forms without converting old EXEC COND usage to IF/THEN/ELSE 
statements at the same time (except possibly for COND on the JOB 
statement).  Also one can use IF/THEN/ELSE in the main JCL stream 
without the bizarre override issues you get with COND on the "EXEC PROC".


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

And the Computer Systems Command was out of Ft. Belvoir, VA and  had 
administrative offices out at the Melpar bldg. on Route 50 along with a  drone 
development pgm out of DARPA. Classes were offered from DODCI at the Naval  
Yard for civilians and military.
 
 
In a message dated 4/18/2012 6:46:58 A.M. Central Daylight Time,  
leful...@sbcglobal.net writes:

could  have been programming classes taught there.  Fort Ben was the  
administrative and financial training  base.



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

Re: Execute certian steps based on input parm

[Jonathan Goossen]

You can pass the symbolic PARM to a program and then have the program set 
the appropriate return code that the JCL can then use the return code for 
branching. In this case you could return 0 or 1.

I often need to execute neither, one or both of two steps. RC=1 or 3 
selects the first. RC=2 or 3 selects the second.

A number of times I have needed to pass symbolic PARMs to programs in 
order to convert them into something for use in the JCL because the 
symbolics don't get interpreted at that point. 

It works. There may be other ways that are not intuitive either.

Thank you and have a Terrific day!

Jonathan Goossen, DTM
ACT Mainframe Storage Group
Personal: 651-361-4541
Department Support Line: 651-361-
For help with communication and leadership skills checkout Woodwinds 
Toastmasters

IBM Mainframe Discussion List  wrote on 04/18/2012 
08:02:20 AM:

> From: Victor Zhang 
> To: IBM-MAIN@bama.ua.edu
> Date: 04/18/2012 08:02 AM
> Subject: Re: Execute certian steps based on input parm
> Sent by: IBM Mainframe Discussion List 
> 
> Ok, the proc is like:
> //ABC PROC VER='620'
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V620
> 
> IF VER NOT = '620' i want proc be:
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V710
> 
> So I code:
> //ABC PROC VER='620'
> //IF620 IF (&VER=620) THEN
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V620
> // ELSE
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V710
> //ENDIF
> 
> But it does not work.
> 
> Please help.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


This e-mail message and all attachments transmitted with it may
contain legally privileged and/or confidential information intended
solely for the use of the addressee(s). If the reader of this
message is not the intended recipient, you are hereby notified that
any reading, dissemination, distribution, copying, forwarding or
other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please
notify the sender immediately and delete this message and all
copies and backups thereof. Thank you.

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

JCL help (yes, with COND)

[Frank Swarbrick]

I have the following job (cut down to include only the relevant parts):


//VAPPROC4 JOB
//BACKUP1  EXEC PROC=SORTBKUP,COND=(4,LT)
//EP4IN    EXEC PROC=EP4IN,COND=(4,LT)
//E4INPRT  EXEC PROC=E4INPRT
//


The EP4IN PROC is a vendor supplied proc as follows:


//EP4IN  PROC
//STEP01 EXEC PGM=IEFBR14,COND=(20,LT)
//STEP01A  EXEC PGM=IEFBR14,COND=(20,LT)
//STEP02 EXEC PGM=EPZOS,COND=(20,LT)
//STEP03   EXEC PGM=IDCAMS,COND=(7,LT)
//STEP04   EXEC PGM=EPTBLUPD
//  IF ( STEP04.RC = 3 ) THEN
//STEP05 EXEC PGM=IEBGENER,COND=((7,LT),(4,LT,STEP03),(4,LT,STEP04))
//  ENDIF
//  IF ( STEP04.RC = 0 | STEP04.RC = 4 ) THEN
//STEPLAST EXEC EPLINK99
//  ENDIF
//EP4IN  PEND
//STEP06 EXEC PGM=IEBGENER,COND=(24,LT)
//STEP07 EXEC PGM=EPX99,COND=(20,LT)
//EP4IN  PROC

I've already solved my issue (which I will detail below), but I'm still unclear 
as to why what I had was wrong, and why my fix actually fixes it.  

The issue is that EP4IN.STEP06 and EP4IN.STEP07 were not being executed:

IEF202I VAPPROC4 STEP06 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES
IEF272I VAPPROC4 STEP06 EP4IN - STEP WAS NOT EXECUTED. 

IEF202I VAPPROC4 STEP07 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES
IEF272I VAPPROC4 STEP07 EP4IN - STEP WAS NOT EXECUTED. 

STEPNAME PROCSTEP    RC
BACKUP1  BACKUP  00
EP4IN    STEP01  00
EP4IN    STEP01A 00
EP4IN    STEP02  00
EP4IN    STEP03  05
EP4IN    STEP04   FLUSH
EP4IN    STEP05   FLUSH
STEPLAST STEP16   FLUSH
STEPLAST STEP17   FLUSH
EP4IN    STEP06   FLUSH
EP4IN    STEP07   FLUSH

(It's expected that EP4IN.STEP04, EP4IN.STEP05, STEPLAST.STEP16 and 
STEPLAST.STEP17 do not execute under these conditions, becasue EP4IN.STEP03 
resulted in RC=05; they execute only when RC=03 for this step.)

Anyway, the solution is to remove the COND parameter from the "EXEC PROC=EP4IN".
My new result follows:

BACKUP1  BACKUP  00
EP4IN    STEP01  00
EP4IN    STEP01A 00
EP4IN    STEP02  00
EP4IN    STEP03  05
EP4IN    STEP04   FLUSH
EP4IN    STEP05   FLUSH
STEPLAST STEP16   FLUSH
STEPLAST STEP17   FLUSH
EP4IN    STEP06  00
EP4IN    STEP07  00
E4INPRT  REPORT  00

What really was the issue and why did my solution resolve it?
My reason for including this parameter is so that EP4IN should be bypassed if 
BACKUP1 fails.

Once again I ponder the sanity of the inventor of COND.

Thanks,
Frank

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

Re: Execute certain steps based on input parm

[Frank Swarbrick]

Whomever it was that invented the entire "COND" construct in JCL was severely 
demented; with the ABENDCC options being only a small part of it!
:-(




>
> From: Joel C. Ewing 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Wednesday, April 18, 2012 11:25 AM
>Subject: Re: Execute certain steps based on input parm
> 
>
>I confess to having less familiarity with ABENDCC keyword forms, never having 
>had a need to use one.  So, "U001" in "ABENDCC=U001" is a "lexical part" of a 
>keyword?  Good Lord, who invented this syntax?  So in the context of an "IF" 
>statement relational expression, "=" is both a relational operator and also a 
>lexical part of such key words as the above.  A rational person familiar with 
>practically any other programming language (and with other JCL relational 
>expressions) would intuitively expect given "ABENDCC=U001" as valid, for 
>"ABENDCC = U001", "ABENDCC EQ U001", and "ABENDCC NE U001" to all be legal 
>syntax, which they apparently are not.  It is a confusing and unnatural 
>syntactic act to permit the same special symbol to serve as both an operator 
>and as part of a keyword!
>
>-- Joel C. Ewing,    Bentonville, AR      jcew...@acm.org    
>
>--
>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: Execute certain steps based on input parm

[Bass, Walter W]

The following can accomplish the same thing without the need to write a
custom program.  This solution is entirely contained within the JCL:

//*
//  SET HEX00=' '   <=== THIS IS A HEX ZERO CHARACTER  
//  SET SYMBL='XYZ'
//*
//* CHECK IF SYMBL=XYZ 
//*
//CKSYMBL  EXEC PGM=IRXJCL,PARM='&HEX00 &SYMBL = XYZ ' 
//*PARM='  &SYMBL = XYZ '  
//SYSEXEC  DD *
  INTERPRET 'RETURN' ARG(1)
//*
//* EXECUTE STEPS BASED ON VALUE OF SMBL1  
//*
//IFXYZIF (CKSYMBL.RC = 1) THEN
//DOTRUE   EXEC PGM=IEFBR14
//*
//ELSE ELSE
//DOFALSE  EXEC PGM=IEFBR14
//ENDIFENDIF   
//*

In the event that you find the non-displayable character in the JCL
objectionable, you can instead create a member in a sysexec lib that
contains the one-line rexx program that is shown above as in-stream,
change the SYSEXEC DD to point to that library and change the parm to
replace the x'00' character with the member name.

Of course that means that you are changing two components (the JCL and
the new REXX pgm) instead of one.  For those of us working for very
large corporations with extreme controls of how/what can be place in
production and the testing involved before that can be done, that may be
a big concern.

Bill Bass
Applications Development Consultant 
United Healthcare
Greenville, SC 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Gilmore
> Sent: Wednesday, April 18, 2012 11:12 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Execute certain steps based on input parm
> 
> John Roberts has resolved your problem.  You need a reusable 
> zero-th step that sets the return code.
> 
> The PL/I procedure
> 
> selstep: procedure(parm) options(main) reorder ;
> 
>  /* sets its return code equal to 1 if its parm value is 'first',
> to 2 if its parm value is 'second', to 0 otherwise */
> 
>  declare parm character(*) parameter nonassignable ;
> 
>  declare pcopy character(16),
>retcode signed binary fixed(31,0) ;
> 
>  declare (first value('first')
>character(5),
>second value('second')
>character(6),
>(x1_retcode value(1),
>x2_retcode value(2),
>F0 value(0))
>signed binary fixed(31,0) ;
>  declare pliretc builtin ;
> 
>  pcopy = parm  ;
>  select (pcopy) ;
>when(first) retcode = x1_retcode ;
>when(second) retcode = x2_retcode ;
>otherwise retcode = F0 ;
>  end ;
>  call pliretc(retcode) ;  /* set jobstep return code */  return ;
> 
> end selstep ;
> 
> does this (and would be easy to extend to choose one of three 
> jobs, etc., etc.); but you can write an analogue in C, even COBOL.
> 
> John Gilmore, Ashland, MA 01721 - USA
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to lists...@bama.ua.edu with the 
> message: INFO IBM-MAIN
> 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

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

Re: Execute certain steps based on input parm

[Joel C. Ewing]

On 04/18/2012 10:51 AM, Paul Gilmartin wrote:

On Wed, 18 Apr 2012 09:47:05 -0500, Joel C. Ewing wrote:


On 04/18/2012 08:46 AM, Paul Gilmartin wrote:

On Wed, 18 Apr 2012 09:30:59 -0400, Veilleux, Jon L wrote:


According to the JCL manual that won't work:

The following keywords are the only keywords supported by IBM and recommended 
for use in relational-expressions. Any other keywords, even if accepted by the 
system, are not intended or supported keywords.


The syntax as "formally" described in the JCL Reference (z/OS 1.12) is
demonstrably incomplete just based on the supplied examples.  Something like
//   IF (&SYM = value) THEN
is clearly valid by the manual's description if&SYM has a numeric value
and "value" is also some numeric constant ...


No.  In:

 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6b0/17.1.4.2

 17.1.4.2 Comparison Operators
 Use comparison operators in a relational-expression to compare a keyword 
with a numeric value.
 ...

There is no mention of using a comparison operator to compare two numeric 
values.
The "keywords" are listed in:

 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6b0/17.1.4.5

Note that "TRUE" and "FALSE" are not themselves keywords nor constant
values; they appear only (and superfluously) in complex tokens such as
"ABEND=TRUE" (which means exactly the same as "ABEND".  Quine would
shudder).

I think I'll submit another RCF.



  But, in their own examples IBM uses as valid constant values things
like "Unnn", "Snnn", "TRUE", "FALSE", none of which are described as


These are not used as constant values, but as lexical parts of "keywords".


keywords and which clearly are not numeric in the normal sense of the
word!  Obviously some special alphanumeric constants are acceptable,
which begs the question why other arbitrary alphanumeric constants that
can't be confused with keywords should not be explicitly allowed as
operands as well.  (Maybe they work even though undocumented, but usage
in that case would be risky!)




If the relational expressions directly supported by JCL are found too
restrictive, one could always write a fairly trivial utility ...


JCL tailoring with ISPF skeletons?

-- gil


ISPF skeletons would only be an alternative if dynamically submitting 
another batch job is acceptable.


The referenced 17.1.4.2 section is very definitely in conflict with the 
actual IF JCL implementation.  I successfully used for years such forms as

IF  (&OPT = 1) THEN
and
IF (&OPT = 0) THEN
where &OPT was set on a prior SET statement to have a value of "0" or 
"1", to allow various job steps to be executed conditionally based on a 
set of "option" statements at the start of the job stream.  Much easier 
than hunting for the job steps, and the expected results of "1 =  1" and 
"0 = 0" being taken as TRUE and "1 = 0" and "0 = 1" being taken as FALSE 
were as intuitively expected.


So does IBM change the docs to agree with the implementation (the 
cheaper solution), or do they change the code to not conflict with the 
docs (which may break existing usage)?  In any event, the existing JCL 
documentation should not be incomplete, confusing, and inconsistent with 
the implementation.  There is a lot to be said for more formal syntax 
and semantic descriptions.


I confess to having less familiarity with ABENDCC keyword forms, never 
having had a need to use one.  So, "U001" in "ABENDCC=U001" is a 
"lexical part" of a keyword?  Good Lord, who invented this syntax?  So 
in the context of an "IF" statement relational expression, "=" is both a 
relational operator and also a lexical part of such key words as the 
above.  A rational person familiar with practically any other 
programming language (and with other JCL relational expressions) would 
intuitively expect given "ABENDCC=U001" as valid, for "ABENDCC = U001", 
"ABENDCC EQ U001", and "ABENDCC NE U001" to all be legal syntax, which 
they apparently are not.  It is a confusing and unnatural syntactic act 
to permit the same special symbol to serve as both an operator and as 
part of a keyword!


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Execute certian steps based on input parm

[Paul Gilmartin]

On Wed, 18 Apr 2012 08:02:20 -0500, Victor Zhang wrote:
>
>So I code:
>//ABC PROC VER='620'
>//IF620 IF (&VER=620) THEN
>//PGMNAME EXEC PGM=PGM
>//STEPLIB DD DNS=LOADMOD.V620
>// ELSE
>//PGMNAME EXEC PGM=PGM
>//STEPLIB DD DNS=LOADMOD.V710
>//ENDIF
> 
A possible drawback of such a scheme is that at job initiation
both data sets will be ENQueued.  Worse, JES3 setup will
require that both data sets be available regardless that only
one will be used.

The ALIAS suggestion is risky.  Job initiation will ENQueue
only on the ALIAS name.  Step initiation will attempt to ENQueue
on the RELATED name; if it is not instantly available the job will
terminate without waiting for it.

-- gil

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

Re: Execute certain steps based on input parm

[Paul Gilmartin]

On Wed, 18 Apr 2012 09:47:05 -0500, Joel C. Ewing wrote:

>On 04/18/2012 08:46 AM, Paul Gilmartin wrote:
>> On Wed, 18 Apr 2012 09:30:59 -0400, Veilleux, Jon L wrote:
>>
>>> According to the JCL manual that won't work:
>>>
>>> The following keywords are the only keywords supported by IBM and 
>>> recommended for use in relational-expressions. Any other keywords, even if 
>>> accepted by the system, are not intended or supported keywords.
>
>The syntax as "formally" described in the JCL Reference (z/OS 1.12) is
>demonstrably incomplete just based on the supplied examples.  Something like
>//   IF (&SYM = value) THEN
>is clearly valid by the manual's description if &SYM has a numeric value
>and "value" is also some numeric constant ...
>
No.  In:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6b0/17.1.4.2

17.1.4.2 Comparison Operators
Use comparison operators in a relational-expression to compare a keyword 
with a numeric value.
...

There is no mention of using a comparison operator to compare two numeric 
values.
The "keywords" are listed in:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6b0/17.1.4.5

Note that "TRUE" and "FALSE" are not themselves keywords nor constant
values; they appear only (and superfluously) in complex tokens such as
"ABEND=TRUE" (which means exactly the same as "ABEND".  Quine would
shudder).

I think I'll submit another RCF.


>  But, in their own examples IBM uses as valid constant values things
>like "Unnn", "Snnn", "TRUE", "FALSE", none of which are described as

These are not used as constant values, but as lexical parts of "keywords".

>keywords and which clearly are not numeric in the normal sense of the
>word!  Obviously some special alphanumeric constants are acceptable,
>which begs the question why other arbitrary alphanumeric constants that
>can't be confused with keywords should not be explicitly allowed as
>operands as well.  (Maybe they work even though undocumented, but usage
>in that case would be risky!)


>If the relational expressions directly supported by JCL are found too
>restrictive, one could always write a fairly trivial utility ...
> 
JCL tailoring with ISPF skeletons?

-- gil

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

Re: Execute certain steps based on input parm

[John Gilmore]

John Roberts has resolved your problem.  You need a reusable zero-th
step that sets the return code.

The PL/I procedure

selstep: procedure(parm) options(main) reorder ;

 /* sets its return code equal to 1 if its parm value is 'first',
to 2 if its parm value is 'second', to 0 otherwise */

 declare parm character(*) parameter nonassignable ;

 declare pcopy character(16),
   retcode signed binary fixed(31,0) ;

 declare (first value('first')
   character(5),
   second value('second')
   character(6),
   (x1_retcode value(1),
   x2_retcode value(2),
   F0 value(0))
   signed binary fixed(31,0) ;
 declare pliretc builtin ;

 pcopy = parm  ;
 select (pcopy) ;
   when(first) retcode = x1_retcode ;
   when(second) retcode = x2_retcode ;
   otherwise retcode = F0 ;
 end ;
 call pliretc(retcode) ;  /* set jobstep return code */
 return ;

end selstep ;

does this (and would be easy to extend to choose one of three jobs,
etc., etc.); but you can write an analogue in C, even COBOL.

John Gilmore, Ashland, MA 01721 - USA

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

[Tom Marchant]

On Wed, 18 Apr 2012 08:18:25 +0530, Jake anderson wrote:

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

Are you sure you want to do that?

Why?

There might be a better solution to whatever problem you are trying to solve.

-- 
Tom Marchant

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

Re: Execute certain steps based on input parm

[Joel C. Ewing]

On 04/18/2012 08:46 AM, Paul Gilmartin wrote:

On Wed, 18 Apr 2012 09:30:59 -0400, Veilleux, Jon L wrote:


According to the JCL manual that won't work:

The following keywords are the only keywords supported by IBM and recommended 
for use in relational-expressions. Any other keywords, even if accepted by the 
system, are not intended or supported keywords.  Also you need to change DNS to 
DSN
...
You will have to get more creative. Perhaps pass a parm that causes an abend in 
a first step?


Or contrive a JCL symbol that evaluates to one of the supported forms.

-- gil



The syntax as "formally" described in the JCL Reference (z/OS 1.12) is 
demonstrably incomplete just based on the supplied examples.  Something like

//   IF (&SYM = value) THEN
is clearly valid by the manual's description if &SYM has a numeric value 
and "value" is also some numeric constant or if "&SYM" resolves to a 
legal keyword value for which "value" is compatible, as legal operands 
are described as keywords or numeric values, and "&SYM" in this context 
would not be a keyword but simply whatever value replaces it.


 But, in their own examples IBM uses as valid constant values things 
like "Unnn", "Snnn", "TRUE", "FALSE", none of which are described as 
keywords and which clearly are not numeric in the normal sense of the 
word!  Obviously some special alphanumeric constants are acceptable, 
which begs the question why other arbitrary alphanumeric constants that 
can't be confused with keywords should not be explicitly allowed as 
operands as well.  (Maybe they work even though undocumented, but usage 
in that case would be risky!)


If the relational expressions directly supported by JCL are found too 
restrictive, one could always write a fairly trivial utility (perhaps 
CBT site already has one) that would accept as a PARM value or an input 
record a more general relational expression (which could include 
parameter references) with syntax that fully supports character string 
comparison and produces a 0|1 (false|true) step condition code that 
could be tested by subsequent conditional JCL statements.  Such a 
utility could even be generalized to allow conditional setting of 
arbitrary step completion codes or even conditionally ABENDing with some 
user ABEND code.


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Execute certian steps based on input parm

[Scott Ford]

Z...
 
Here is another approach i use this:
 
//BULDREL  JOB SYSTEMS,MSGLEVEL=(1,1),MSGCLASS=X,CLASS=A,PRTY=8,
// NOTIFY=&SYSUID,REGION=0M
//*--*
//*  BUILD FOR IDF RACF RELEASES *
//*  . PRODEXP = EXPRESS PIONEER ONLY    *
//*  . PRODENT = ENTERPRISE EDITION  *
//*  . PROD    = ORACLE RELEASE  *
//*--*
//SETP1  SET   ITYPE=PROD
//SETP2  SET   OTYPE=PROD
//SETO   SET   ORG=IDF
//SETH1  SET   IHLQ=ORA9418
//SETH2  SET   OHLQ=ORA9419
//SET1I  SET   IDSN=&ORG..&ITYPE..&IHLQ..JCLLIB
//SET1O  SET   ODSN=&ORG..&OTYPE..&OHLQ..JCLLIB
//SETM1  SET   ORECFM=FB
//SETM2  SET   OLRECL=80
//SETM3  SET   OBLOCK=3120
//SETM4  SET   OVOLSER=JASYS3
//SET2I  SET   IDSN1=&ORG..&ITYPE..&IHLQ..PROCLIB
//SET2O  SET   ODSN1=&ORG..&OTYPE..&OHLQ..PROCLIB
//SET3I  SET   IDSN2=&ORG..&ITYPE..&IHLQ..PARMLIB
//SET3O  SET   ODSN2=&ORG..&OTYPE..&OHLQ..PARMLIB
//SET4I  SET   IDSN3=&ORG..&ITYPE..&IHLQ..LINKLIB
//SET4O  SET   ODSN3=&ORG..&OTYPE..&OHLQ..LINKLIB
//SET5I  SET   IDSN4=&ORG..&ITYPE..&IHLQ..CLISTLIB
//SET5O  SET   ODSN4=&ORG..&OTYPE..&OHLQ..CLISTLIB
//STEP1  EXEC  PGM=IEFBR14
//*---*
//*  IEFBR14 ALLOC OUTPUT LIBRARIES
//*---*
//INDD1  DD    DSN=&ODSN,
//   DCB=(DSORG=PO,RECFM=&ORECFM,LRECL=&OLRECL,
//   BLKSIZE=&OBLOCK),UNIT=SYSDA,SPACE=(TRK,(300,100,60)),
//   DISP=(NEW,CATLG),VOL=SER=&OVOLSER
//INDD2  DD    DSN=&ODSN1,
//   DCB=(DSORG=PO,RECFM=&ORECFM,LRECL=&OLRECL,
//   BLKSIZE=&OBLOCK),UNIT=SYSDA,SPACE=(TRK,(300,100,60)),
//   DISP=(NEW,CATLG),VOL=SER=&OVOLSER
//INDD3  DD    DSN=&ODSN2,
//   DCB=(DSORG=PO,RECFM=&ORECFM,LRECL=&OLRECL,
//   BLKSIZE=&OBLOCK),UNIT=SYSDA,SPACE=(TRK,(300,100,60)),
//   DISP=(NEW,CATLG),VOL=SER=&OVOLSER
//INDD4  DD    DSN=&ODSN4,
//   DCB=(DSORG=PO,RECFM=&ORECFM,LRECL=&OLRECL,
//   BLKSIZE=&OBLOCK),UNIT=SYSDA,SPACE=(TRK,(300,100,60)),
//   DISP=(NEW,CATLG),VOL=SER=&OVOLSER
//INDD5  DD    DSN=&ODSN3,
//   DCB=(DSORG=PO,RECFM=U,LRECL=0,
//   BLKSIZE=6144),UNIT=SYSDA,SPACE=(TRK,(2000,100,60)),
//   DISP=(NEW,CATLG),VOL=SER=&OVOLSER
//IFGOD1 IF (STEP1.RC = 0) THEN
 
..so on so forth.

Depends on what you are doing ...

Scott J Ford
Software Engineer
http://www.identityforge.com
 
 


 From: Bill Ashton 
To: IBM-MAIN@bama.ua.edu 
Sent: Wednesday, April 18, 2012 9:51 AM
Subject: Re: Execute certian steps based on input parm
  
Why not pass the the version in as a symbolic:
//ABC PROC VER=620
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.V&ver

Then you can call it from your JCL:
//STEP1  EXEC PROC=ABC,VER=620    or
//STEP1  EXEC PROC=ABC      (This will default to 620)

and then if you have a new version, you can change some JCL:
//STEP2  EXEC PROC=ABC,VER=710

Another option, if you want to change the version all at once, is to use
dataset alias definitions.
To do this, you set your proc up like this:
//ABC PROC
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.PROD.VERSION

Then, your JCL would have only this:
//STEP1  EXEC PROC=ABC

To set this up, you would use IDCAMS like this:
//STEP0    EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  DEL            LOADMOD.PROD.VERSION   ALIAS
  DEF ALIAS(NAME(LOADMOD.PROD.VERSION) -
             REL(LOADMOD.V620))

That way, everyone who uses LOADMOD.PROD.VERSION, in JCL or ISPF browse,
etc, will automatically get LOADMOD.V620.

Then, when you want to upgrade, you just run the IDCAMS for the new version:
//STEP0    EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  DEL            LOADMOD.PROD.VERSION   ALIAS
  DEF ALIAS(NAME(LOADMOD.PROD.VERSION) -
             REL(LOADMOD.V710))

Your proc doesn't need to change, your JCL doesn't change, any CLIST or
REXX programs don't change, and everything processes the same way, just on
a different version.

Of course before you upgrade, you can perform testing by either using a JCL
STEPLIB override to the absolute version, or you can define an alias of
LOADMOD.TEST.VERSION... This will give you a lot of options, if this is
what you are looking for.

I hope this is some help to you.
Billy



On Wed, Apr 18, 2012 at 9:02 AM, Victor Zhang wrote:

> Ok, the proc is like:
> //ABC PROC VER='620'
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V620
>
> IF VER NOT = '620' i want proc be:
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V710
>
> So I code:
> //ABC PROC VER='620'
> //IF620 IF (&VER=620) THEN
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V620
> //     ELSE
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V710
> //    ENDIF
>
> But it does not work.
>
> Please help.
>
> -

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

[Kirk Wolf]

On Tue, Apr 17, 2012 at 10:33 PM, John McKown  wrote:

> 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.
>
> Spoiled by common sense :-)   z/OS Unix commands should not be walled out
from z/OS datasets.


> 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.
>
> Its especially silly considering that BPAM already supports reading
concatenations of  PDS[E] and Unix directories.Apparently, the cob2
developer, or maybe the underlying COBOL compiler has "protected" itself
from this support.

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.
>
> Or with a pretty simple REXX shell script.   It might be that the COBOL
compiler (IGYCRCTL) has open exits that detects SYSLIB mixed PDS/Unix
contatenations (but unlikely I would guess).


> 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.
>
> see signal()


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

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

Re: Execute certain steps based on input parm

[Roberts, John J]

Another option is to pass the parameter as PARM information to a first step.  
The program for the first step would inspect the PARM and set its return code 
accordingly.  Subsequent steps could be made conditional on the return code of 
this first step.

John

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

[Mark Zelden]

On Tue, 17 Apr 2012 23:50:46 -0700, Walter Marguccio 
 wrote:

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

Yes, but a warning to Jake who seems to not have a lot of 
experience (no offense meant):

If you use that exec to "undo" indirect cataloging, *YOU MUST* change 
"DEVT()"  to "DEVT(3390)"   (assuming you are not using something
like a P/390 with 3380 DASD) before submitting the IDCAMS job.

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: Execute certian steps based on input parm

[Bill Ashton]

Why not pass the the version in as a symbolic:
//ABC PROC VER=620
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.V&ver

Then you can call it from your JCL:
//STEP1  EXEC PROC=ABC,VER=620or
//STEP1  EXEC PROC=ABC  (This will default to 620)

and then if you have a new version, you can change some JCL:
//STEP2  EXEC PROC=ABC,VER=710

Another option, if you want to change the version all at once, is to use
dataset alias definitions.
To do this, you set your proc up like this:
//ABC PROC
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.PROD.VERSION

Then, your JCL would have only this:
//STEP1  EXEC PROC=ABC

To set this up, you would use IDCAMS like this:
//STEP0EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSINDD  *
  DELLOADMOD.PROD.VERSION   ALIAS
  DEF ALIAS(NAME(LOADMOD.PROD.VERSION) -
 REL(LOADMOD.V620))

That way, everyone who uses LOADMOD.PROD.VERSION, in JCL or ISPF browse,
etc, will automatically get LOADMOD.V620.

Then, when you want to upgrade, you just run the IDCAMS for the new version:
//STEP0EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSINDD  *
  DELLOADMOD.PROD.VERSION   ALIAS
  DEF ALIAS(NAME(LOADMOD.PROD.VERSION) -
 REL(LOADMOD.V710))

Your proc doesn't need to change, your JCL doesn't change, any CLIST or
REXX programs don't change, and everything processes the same way, just on
a different version.

Of course before you upgrade, you can perform testing by either using a JCL
STEPLIB override to the absolute version, or you can define an alias of
LOADMOD.TEST.VERSION... This will give you a lot of options, if this is
what you are looking for.

I hope this is some help to you.
Billy



On Wed, Apr 18, 2012 at 9:02 AM, Victor Zhang wrote:

> Ok, the proc is like:
> //ABC PROC VER='620'
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V620
>
> IF VER NOT = '620' i want proc be:
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V710
>
> So I code:
> //ABC PROC VER='620'
> //IF620 IF (&VER=620) THEN
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V620
> // ELSE
> //PGMNAME EXEC PGM=PGM
> //STEPLIB DD DNS=LOADMOD.V710
> //ENDIF
>
> But it does not work.
>
> Please help.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>



-- 
Thank you and best regards,
*Billy Ashton*

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

Re: Execute certain steps based on input parm

[Paul Gilmartin]

On Wed, 18 Apr 2012 09:30:59 -0400, Veilleux, Jon L wrote:

>According to the JCL manual that won't work:
>
>The following keywords are the only keywords supported by IBM and recommended 
>for use in relational-expressions. Any other keywords, even if accepted by the 
>system, are not intended or supported keywords.  Also you need to change DNS 
>to DSN
>...
>You will have to get more creative. Perhaps pass a parm that causes an abend 
>in a first step?
> 
Or contrive a JCL symbol that evaluates to one of the supported forms.

-- gil

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

Re: Execute certain steps based on input parm

[Veilleux, Jon L]

According to the JCL manual that won't work: 

The following keywords are the only keywords supported by IBM and recommended 
for use in relational-expressions. Any other keywords, even if accepted by the 
system, are not intended or supported keywords.  Also you need to change DNS to 
DSN


Keyword Use 

RC 
indicates a return code 
ABEND 
indicates an abend condition occurred 
¬ABEND 
indicates no abend condition occurred 
ABENDCC 
indicates a system or user completion code 
RUN 
indicates that the specified step started execution 
¬RUN 
indicates that the specified step did not start execution

You will have to get more creative. Perhaps pass a parm that causes an abend in 
a first step?

//ABC PROC VER='X14'   This will run first step
//STEP1 EXEC PGM=IEFBR&VER
//IF620 IF (ABEND) THEN
//PGMNAME EXEC PGM=IEFBR14
//DD1 DD DSN=somefile,DISP=SHR
// ELSE
//PGMNAME EXEC PGM=IEFBR14
//DD2 DD DSN=somefile,DISP=SHR
//ENDIF
//  PEND
//TEST  EXEC ABC

//ABC PROC VER='X14'   This will run second step
//STEP1 EXEC PGM=IEFBR&VER
//IF620 IF (ABEND) THEN
//PGMNAME EXEC PGM=IEFBR14
//DD1 DD DSN=somefile,DISP=SHR
// ELSE
//PGMNAME EXEC PGM=IEFBR14
//DD2 DD DSN=somefile,DISP=SHR
//ENDIF
//  PEND
//TEST  EXEC ABC


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Victor Zhang
Sent: Wednesday, April 18, 2012 9:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Execute certian steps based on input parm

Ok, the proc is like:
//ABC PROC VER='620'
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.V620

IF VER NOT = '620' i want proc be:
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.V710

So I code:
//ABC PROC VER='620'
//IF620 IF (&VER=620) THEN
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.V620
// ELSE
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.V710
//ENDIF

But it does not work.

Please help.

--
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: Query about overcoming -- debunking, countering, and burying --mainframe myths

[Clark Morris]

On 17 Apr 2012 18:13:15 -0700, in bit.listserv.ibm-main you wrote:

>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."
> 
I was a contract programmer at an HP-UX shop that had converted from a
mainframe.  They used UNI-KIX and UNI-SPF and a shell that emulated
JCL in many ways.  SYNCSORT there made the mainframe version look
brain dead.  What was interesting is that I didn't have the foggiest
notion of what the machine architecture was or the instruction set.  I
was able to debug the problems using various tools and eliminate some
long standing bugs.  

Even in IBM z series COBOL, other than knowing the current instruction
and the appropriate data areas, things that are useful for Assembler
programmers aren't that meaningful in most instances for COBOL
programmers.  Intermodule linkage can be more complex due to the
dynamic call options and the way control flow is handled.  

Clark Morris

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

Re: Execute certian steps based on input parm

[Victor Zhang]

Ok, the proc is like:
//ABC PROC VER='620'
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.V620

IF VER NOT = '620' i want proc be:
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.V710

So I code:
//ABC PROC VER='620'
//IF620 IF (&VER=620) THEN
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.V620
// ELSE
//PGMNAME EXEC PGM=PGM
//STEPLIB DD DNS=LOADMOD.V710
//ENDIF

But it does not work.

Please help.

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

[Kurt Quackenbush]

Presumably an output PDS for file tailoring within the SMP/E dialogs.
You might want to make it a per-user data set.


No no no.  SMPTABL is an ISPF table data set intended to be shared by 
all your SMP/E dialog users. 
(http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/gimusr51/3.6.3?SHELF=gim2bk90&DT=20110811181158)


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: PL/I with variable PLISTs (was: LE C calling HLASM)

[McKown, John]

What about the ASMA90 program? It can be invoked via JCL and process the PARM=. 
But it can also be LINK'd to or ATTACH[X]'d. In this latter case, The parmlist 
passed in via GPR1 can have more than one entry. The others are for things like 
overriding DD names. Many of IBM's utilities (such as IDCAMS) use this 
facility. I have written a program which invokes IDCAMS and redirects the 
"SYSIN" and "SYSPRINT" DD statement to a subroutine in my code so that I could 
send a command to IDCAMS and then get the result back, in order to futher 
process it.

-- 
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 Bernd Oppolzer
> Sent: Wednesday, April 18, 2012 3:32 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PL/I with variable PLISTs (was: LE C calling HLASM)
> 
> Why? I don't understand this comment, because JCL parm is always only 
> one parm;
> no variable length address list ... what do I get wrong? 
> Well, the JCL 
> parm itself has
> variable length, but the length of the address list is fixed, always 
> one. And: I dont know
> if the system sets the high order bit of the address of the 
> JCL parm - I 
> just don't care.
> 
> Kind regards
> 
> Bernd
> 
> 
> 
> Am 18.04.2012 01:06, schrieb 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.
> >
> 
> --
> 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]

Fort Huachuca is in Arizona, and when I was in the Army was the training base 
for some of the communications stuff.  The other communications training was 
Fort Monmouth, New Jersey.

I believe that Fort Huachuca also had some intelligence schools there.  That 
could have been programming classes taught there.  Fort Ben was the 
administrative and financial training base.

Lloyd



- Original Message 
From: Ed Gould 
To: IBM-MAIN@bama.ua.edu
Sent: Wed, April 18, 2012 1:03:56 AM
Subject: Re: GO TO "cobol"

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

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

Re: zfs fails to start

[Patrick Loftus]

Just found this information related to the ZFS delay I'd had, which I'd filed 
away. It's copied from a redpiece. I chopped bits out here and there I think, 
but the full text is in the following Redpiece:
http://www.redbooks.ibm.com/redpieces/pdfs/sg246580.pdf

2.12.2 Mounting zFS file systems copied outside the sysplex
If you have a specific system located in another sysplex that is used for 
preparing and servicing UNIX System Services file systems that are type zFS, 
then the first mount may take at least 65 seconds. This is caused by the write 
protection implementation.

As long as the aggregate is attached read-write, the identifier is active in 
block zero (0). As a result, on ADRDSSU COPY or DUMP processing, it is copied 
as well.

When you mount or attach the aggregate in the target production system, zFS 
sees this identifier. Because it does not reflect the sysplex environment, zFS 
waits 65 seconds for an update of the time stamp value within the identifier. 
If the aggregate is used read-write outside of the sysplex, then this time 
stamp should get updated twice a minute, as mentioned earlier.
If no update occurs, this shows that the identifier is there without a reason. 
In this case, after the 65 seconds, zFS attaches and mounts the aggregate.

To avoid the 65 seconds wait time on access to the aggregate in the production 
environment, unmount or detach the source aggregate in the service system 
before using ADRDSSU COPY or ADRDSSU DUMP.
OR
Switch the source aggregate to read-only access, using the ISHELL modify 
interface from the mount table panel or the /usr/sbin/chmount shell command. 
Then copy the contents of the aggregate. This switch removes the write 
protection identifier, as well.

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

Re: Execute certian steps based on input parm

[Elardus Engelbrecht]

Victor Zhang wrote:

>I want to achieve:
>if input parm is A:
>execute job step1
>else execute job step2

>Is it possible to do it using if/then/else or other methods without coding a 
>program?

Where and in what format is your parm?

Give us an example on what you want to do.

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

SV: SV: GO TO "cobol"

[Thomas Berg]

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
> Shmuel Metz (Seymour J.)
> Skickat: den 18 april 2012 01:26
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: SV: GO TO "cobol"
> 
> 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.
> 

This somewhat reminds me of how I use Signal in error situations.  I do a "CALL 
ERROR_AND_EXIT"  with propriate msg etc. and in that procedure, after some 
tidying and logging, do a Signal to the exit routine. 

But the idea with the interprocedure enhanced Leave is interesting. 




Regards,
Thomas Berg
__
Thomas Berg   Specialist   AM/DQS   SWEDBANK AB (publ)


  

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

Re: Execute certian steps based on input parm

[Binyamin Dissen]

On Wed, 18 Apr 2012 04:25:12 -0500 Victor Zhang 
wrote:

:>Hello,
:>I want to achieve:
:>if input parm is A:
:>execute job step1
:>else execute job step2
:>
:>Is it possible to do it using if/then/else or other methods without coding a 
program?

How is the "input parm" passed?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Execute certian steps based on input parm

[Victor Zhang]

Hello,
I want to achieve:
if input parm is A:
execute job step1
else execute job step2

Is it possible to do it using if/then/else or other methods without coding a 
program?

regards
Victor

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

[Bernd Oppolzer]

Why? I don't understand this comment, because JCL parm is always only 
one parm;
no variable length address list ... what do I get wrong? Well, the JCL 
parm itself has
variable length, but the length of the address list is fixed, always 
one. And: I dont know
if the system sets the high order bit of the address of the JCL parm - I 
just don't care.


Kind regards

Bernd



Am 18.04.2012 01:06, schrieb 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.



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

[John Blythe Reid]

Thanks Peter. They re-IPLed that LPAR on Sunday so that cleaned everything
up.

Regards,
John.



On 17 April 2012 17:31, Peter Relson  wrote:

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



-- 
John Blythe Reid,
Técnico de Sistemas de z/OS y de Sistemas Transaccionales,
Barcelona,
España.

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

[Alvaro Guirao Lopez]

Linda,


Thank you very much, your info is being very useful.

2012/4/18 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
>



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

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

[Terry Sambrooks]

Hi Tom,

In respect of your recent post on the issue of the title, and your last
paragraph:

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

In Chapter 23 "Compiler direction statements" Page 520 contains information
about the COPY Statement which states:

"When compiling from JCL or TSO, only the first eight characters are used as
the identifying name. When compiling with 
the cob2 command and processing COPY text residing in the Hierarchical File
System (HFS), all characters are significant."

By implication the restriction information is in the manual so perhaps a
cross reference of the two items is all that is required.

Kind Regards - Terry
 
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
 
Reg : 3767263
 
Outgoing e-mails have been scanned, but it is the recipients responsibility
to ensure their anti-virus software is up to date.
 
 


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