IBM Mainframe JCL Conversion Tools
Colin Campbell
COND= to IF ... THEN ... ELSE ... ENDIF?
We can't forbid the use of COND= in our JCL Standards Checker (which is
written in COBOL, so that I'm not 100% off topic), because there is so
much use of COND= in existing jobs.
If I could get all existing uses converted, then we could prohibit the
keyword entirely.
Thanks,
Colin
Ron
statements in JCL and do use them frequently. However,
I also routinely put COND=(0,NE) on just about every
step to prevent it from executing if a prior step
ended with a condition code greater than zero. I've
seen this in a lot of shops. It seems do me having
to enclose each step with an IF ENDIF sequence to
accomplish the same thing would be more confusing and
complicated than the COND parameter. Would you really
want to prevent COND from being used in that manner?
Michael Mattias
news:QcWdnRrW3Y5...@giganews.com...
Not sure ... but it seems to me mixing IF..ELSE with COND= in a single job
might make maintenance a real 'challenge' for the next poor schlub.
MCM
Ira Baxter
"Volker Bandke" <vba...@bsp-gmbh.com> wrote in message
news:2jgp10t0c7jbbrhl3...@4ax.com...
> On Thu, 29 Jan 2004 16:09:55 -0800, Colin Campbell
> <cmc...@adelphia.net_remove_this> wrote:
>
> >Does anyone know of tools which will convert the horrible JCL construct
> >COND= to IF ... THEN ... ELSE ... ENDIF?
>
>
> I am not aware of a mechanical/programmatical way of doing this
Not available off the shelf, but we build program transformation tools
for arbitrary languages. We have a draft version of JCL available for
our tools. This looks like a pretty easy transform to code.
See http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html.
--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Thane Hubbell
the mainframe?
Colin Campbell <cmc...@adelphia.net_remove_this> wrote in message news:<ohhSb.561$b77....@dfw-service2.ext.raytheon.com>...
Ubiquitous
cmc...@adelphia.net_remove_this wrote:
One can use IF ... THEN statements in JCL?
--
======================================================================
ISLAM: Winning the hearts and minds of the world, one bomb at a time.
Doug Scott
> One can use IF ... THEN statements in JCL?
Yep. You wouldn't want to, but JCl is such a hideous construct, that
there's no way it can be improved.
My advice is to get used to it. There are software packages which will
generate JCL from sensible syntax, but IBM haven't provided any.
---
Doug
Howard Brazee
On 20-Aug-2004, web...@polaris.net (Ubiquitous) wrote:
> >Does anyone know of tools which will convert the horrible JCL construct
> >COND= to IF ... THEN ... ELSE ... ENDIF?
> >
> >We can't forbid the use of COND= in our JCL Standards Checker (which is
> >written in COBOL, so that I'm not 100% off topic), because there is so
> >much use of COND= in existing jobs.
> >
> >If I could get all existing uses converted, then we could prohibit the
> >keyword entirely.
>
> One can use IF ... THEN statements in JCL?
You might be surprised about how many people use JCL without knowing this.
Give them the following link:
Howard Brazee
On 20-Aug-2004, Doug Scott <dws...@ieee.org> wrote:
> > One can use IF ... THEN statements in JCL?
>
> Yep. You wouldn't want to, but JCl is such a hideous construct, that
> there's no way it can be improved.
Why wouldn't we want to use IF ... THEN statements in JCL? They're clear,
easy, and useful.
What does JCI stand for? I infer by the "hideous construct" phrase that it has
something to do with the old COND logic.
Robert Wagner
wrote:
>In article <ohhSb.561$b77....@dfw-service2.ext.raytheon.com>,
>cmc...@adelphia.net_remove_this wrote:
>
>>Does anyone know of tools which will convert the horrible JCL construct
>>COND= to IF ... THEN ... ELSE ... ENDIF?
>>
>>We can't forbid the use of COND= in our JCL Standards Checker (which is
>>written in COBOL, so that I'm not 100% off topic), because there is so
>>much use of COND= in existing jobs.
>>
>>If I could get all existing uses converted, then we could prohibit the
>>keyword entirely.
>
>One can use IF ... THEN statements in JCL?
One can, but it's so crippled that it's unusable. The construct under
IF must be a complete STEP. One cannot say:
// IF (RC LT 9) THEN
// MYDD DD DSN='A'
// ELSE
// MYDD DD DSN='B'
// ENDIF
COND has the same limitation, it goes on the EXEC statement, so
converting COND to IF should be trivial. It could be written as an
ISPF macro, then submitted to batch with * filename to convert all
JCL in a PDS.
Ubiquitous
>> One can use IF ... THEN statements in JCL?
>
>Yep. You wouldn't want to, but JCl is such a hideous construct, that
>there's no way it can be improved.
I've used COND in mine from the begining but they're such a bear.
I was hoping there was an easier alternative.
Robert Wagner
wrote:
>On 20-Aug-2004, Doug Scott <dws...@ieee.org> wrote:
>
>> > One can use IF ... THEN statements in JCL?
>>
>> Yep. You wouldn't want to, but JCl is such a hideous construct, that
>> there's no way it can be improved.
>
>Why wouldn't we want to use IF ... THEN statements in JCL? They're clear,
>easy, and useful.
>What does JCI stand for?
A lower case L in some fonts. When I told Agent to switch to Courier,
it showed up as an L.
> I infer by the "hideous construct" phrase that it has
>something to do with the old COND logic.
As a scripting language, JCL is horrid. Assuming you're running W2K or
later, you need look no further than the computer before you for
excellent scripting languages. It's amazing how many people think DOS
.bat file is the only MS script language, even 'professional'
administrators. The full spec is at the URL at the end of this
message. Before you read it, I'll give two very simple demos. Copy and
paste this into a text file named demo1.vbs
Set wbemObjectSet = _
GetObject("winmgmts:\\.").InstancesOf("Win32_Service")
For Each wbemObject In wbemObjectSet
If wbemObject.State = "Running" Then
WScript.Echo " Service: " & wbemObject.DisplayName
End If
Next
Now run it by typing "cscript demo1.vbs". The output will show all
services running on your PC. The list might convince you you're not
running a 'toy computer'.
Next you might wonder what other information about a service, in
addition to DisplayName, is available. Look in the documentation? No,
look in the class definition. This is called 'introspection'. It's
available for ALL objects in object-land. Copy and paste this into a
text file named demo2.vbs and run it with "cscript demo2.vbs".
Set objClass = GetObject("winmgmts:\\.\root\cimv2:Win32_Service")
For Each objClassProperty In objClass.Properties_
WScript.Echo objClassProperty.Name
Next
The output should look like this:
AcceptPause
AcceptStop
Caption
CheckPoint
CreationClassName
Description
DesktopInteract
DisplayName
ErrorControl
ExitCode
InstallDate
Name
PathName
ProcessId
ServiceSpecificExitCode
ServiceType
Started
StartMode
StartName
State
Status
SystemCreationClassName
SystemName
TagId
WaitHint
If you're on a MS network, replacing the dot with the name of another
machine will give the same information about that machine. You don't
have to log onto its command line. You can just as easily list methods
available against services. This is now software should work .. IMO.
VBScript offers variables, loops, case statement, if .. then .. else,
local functions, call, editing pictures, math functions, string
functions, access to the OS API and the world of OO. JCL doesn't offer
any of that .. except IF around whole steps in batch jobs.
Don Leahy
news:nu6di0t2tl9humgnu...@4ax.com...
> On Fri, 20 Aug 2004 20:28:04 GMT, "Howard Brazee" <how...@brazee.net>
> wrote:
>
> >On 20-Aug-2004, Doug Scott <dws...@ieee.org> wrote:
> >
> >> > One can use IF ... THEN statements in JCL?
> >>
> >> Yep. You wouldn't want to, but JCl is such a hideous construct, that
> >> there's no way it can be improved.
> >
> >Why wouldn't we want to use IF ... THEN statements in JCL? They're
clear,
> >easy, and useful.
>
> >What does JCI stand for?
>
> A lower case L in some fonts. When I told Agent to switch to Courier,
> it showed up as an L.
>
> > I infer by the "hideous construct" phrase that it has
> >something to do with the old COND logic.
>
> As a scripting language, JCL is horrid. Assuming you're running W2K or
> later, you need look no further than the computer before you for
> excellent scripting languages. It's amazing how many people think DOS
> .bat file is the only MS script language, even 'professional'
> administrators.
> VBScript offers variables, loops, case statement, if .. then .. else,
> local functions, call, editing pictures, math functions, string
> functions, access to the OS API and the world of OO. JCL doesn't offer
> any of that .. except IF around whole steps in batch jobs.
Yes, but JCL isn't the only scripting language on z/OS. Complex scripts
can easily be handled through TSO Rexx.
Joe Zitzelberger
web...@polaris.net (Ubiquitous) wrote:
> In article <ohhSb.561$b77....@dfw-service2.ext.raytheon.com>,
> cmc...@adelphia.net_remove_this wrote:
>
> >Does anyone know of tools which will convert the horrible JCL construct
> >COND= to IF ... THEN ... ELSE ... ENDIF?
> >
> >We can't forbid the use of COND= in our JCL Standards Checker (which is
> >written in COBOL, so that I'm not 100% off topic), because there is so
> >much use of COND= in existing jobs.
> >
> >If I could get all existing uses converted, then we could prohibit the
> >keyword entirely.
>
> One can use IF ... THEN statements in JCL?
I can't think of a product -- but if you have an inhouse Cobol standards
checker, why not make it into a preprocessor.
The rules for converting a COND to an IF are simple as COND is only a
single step. Have your checker emit an IF/ENDIF around each step with a
cond, and proper convert the COND condtion to an IF condtion.
It isn't perfect. You will see two IFs with opposite conditons instead
of an IF/ELSE/ENDIF. But it doesn't totally suck either.
Robert Wagner
<leah...@nospamplease.netscape.net> wrote:
>Yes, but JCL isn't the only scripting language on z/OS. Complex scripts
>can easily be handled through TSO Rexx.
In the case of batch, Rexx writes the JCL and CA-7 executes it.
Running production programs running under Rexx is not in the culture.
This source says there are others, one being Python.
http://encyclopedia.thefreedictionary.com/Scripting%20language
Don Leahy
"Robert Wagner" <rob...@wagner.net.yourmammaharvests> wrote in message
> On Sat, 21 Aug 2004 10:01:08 -0400, "Don Leahy"
> <leah...@nospamplease.netscape.net> wrote:
>
> >Yes, but JCL isn't the only scripting language on z/OS. Complex scripts
> >can easily be handled through TSO Rexx.
>
> In the case of batch, Rexx writes the JCL and CA-7 executes it.
> Running production programs running under Rexx is not in the culture.
And your point is?
LX-i
I'll preface this by saying that I've never used JCL a nanosecond in my
life - so this may not apply. However, in the case you describe above,
is it possible for the COND statement to modify the value it's checking
if a true condition occurs?
This may not even be a factor, but I know there's a difference between
this...
if myVar = "X"
perform NextMyVar
else
perform MyVarIsDone
end-if
.
NextMyVar.
move "Y" to myVar.
...and this...
if myVar = "X"
perform NextMyVar
end-if
if myVar not = "X"
perform MyVarIsDone
end-if
.
In the first, MyVarIsDone is not performed - under the second, it is.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi...@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Glenn Someone
relatable to those with assembly experience, though. But a
counterintuitive nightmare for those of us who don't.
On Fri, 20 Aug 2004 21:02:48 +0100, Doug Scott <dws...@ieee.org>
wrote:
Robert Wagner
<leah...@nospamplease.netscape.net> wrote:
>
>"Robert Wagner" <rob...@wagner.net.yourmammaharvests> wrote in message
>news:q4jfi05tbjpbga26i...@4ax.com...
>> On Sat, 21 Aug 2004 10:01:08 -0400, "Don Leahy"
>> <leah...@nospamplease.netscape.net> wrote:
>>
>> >Yes, but JCL isn't the only scripting language on z/OS. Complex scripts
>> >can easily be handled through TSO Rexx.
>>
>> In the case of batch, Rexx writes the JCL and CA-7 executes it.
>> Running production programs under Rexx is not in the culture.
>
>And your point is?
My point is what's permissible is more a function of culture than of
language. The standard in the mainframe world is the Golden Age of
the '70s. They act like it might return any day. Pleasant dreams.
Lawrence H Greenwald
LX-i <lxi...@netscape.net> wrote:
>
> I'll preface this by saying that I've never used JCL a nanosecond in my
> life - so this may not apply. However, in the case you describe above,
> is it possible for the COND statement to modify the value it's checking
> if a true condition occurs?
>
Having worked on IBM mainframes for over 20 years, I've seen COND and
how bad it can be. Sorry, COND can only be used to check for a return
code from a prior step or if a prior step has abended. The problem with
COND is that it's bass-ackwards of what you would think would happen...
If you've never seen it, typical use (overly simplified to save space)
is this...
//A EXEC PGM=AAA123
/*
//B EXEC PGM=XYZ456,COND=(12,GT,A)
/*
Now program AAA123 can set a return code (a value in register 15) just
prior to exiting and step B will examine the value.
If A returns a return code of, say, 10...then the expression is "is 12
greater than 10?", then the condition is evaluated as TRUE and (here's
where it's bass-ackwards), step B is BYPASSED (program XYZ456 is NOT
executed)!!!
If A returns a return code of, say, 14...then the condition is evaluated
as FALSE and the step B (program XYZ456) is EXECUTED!!
You think it's bad with one code, try it with multiple codes from
multiple steps!! Yech!!
There's also COND=ONLY, which means execute the step ONLY if a prior
step ABENDED (divide by zero error, doing math on a field with invalid
numeric data, ran out of space for an output file on disk, etc.)
There's also COND=EVEN, which means exeute the step EVEN if a prior step
abended (usually steps after an abend are bypassed, unless the COND=ONLY
or COND=EVEN is coded for a step or steps).
MVS Version 4 (circa 1996 or so...don't quote me on this) added the
IF...THEN...ELSE which makes life a lot easier.
--LG
--
reply to - lgreenwa at cts dot com
"I'm looking over a three-leaf clover that I overlooked be-three!" --Bugs Bunny
Don Leahy
Alistair Maclean
nightmare, especially where people cond-code every step when they don't
need to do so.
In message <7rggi0do28hqurmaj...@4ax.com>, Glenn Someone
<donts...@whydoyouneedmyaddressspammers.com> writes
--
Alistair Maclean
For Entropy is a harsh mistress.
- Stanislaw Lem
Robert Wagner
<lgre...@cts.com> wrote:
>If you've never seen it, typical use (overly simplified to save space)
>is this...
>
>//A EXEC PGM=AAA123
>/*
>//B EXEC PGM=XYZ456,COND=(12,GT,A)
>/*
>
>Now program AAA123 can set a return code (a value in register 15) just
>prior to exiting and step B will examine the value.
In three out of three mainframe shops where I worked recently, the
rule was one step per JCL. They used the scheduler to make decisions,
not JCL. When I tried to put two related steps in a single job, I was
told that's against the rules.
When converting to Unix, which they hated, they insisted on knowing
how to make a job abend. The conversation went like this:
MF: How can we make the job abend?
me: Why do you want to stop the job? Just log the offending
transaction and keep running.
MF: Nobody looks at logs. We must get a human involved so the problem
will be noticed. Maybe we can divide by zero.
me: Ok, you can abend by saying CALL 'abort' RETURNING some-value.
MF: Where's it say that in the Cobol manual?
me: It doesn't. You're calling a C function.
MF: Huh? A C function? Can that be done?
MF: Next question .. how do we read a dump?
me: Reading dumps is not in the Unix culture. Just log the offending
value and its key.
MF: No, we've always read dumps. There might be other information we
didn't log.
me: (Show them how to use coreadm so dumps don't overwrite each other.
Show them how to use anim to read a dump using source as a template.)
MF: This is great. We just point to a data name and it shows the
value.
me: Make sure you use the -g compiler option so it can relate
addresses to source.
(Later notice some Standards Guy turned off -g for production
compilations.)
me: They won't be able to do production support without that option.
SG: We can't have people debugging programs in Production. They should
go to a test environment.
me: Addresses won't match because you changed other compiler options.
SG: So copy the transaction file and recreate the problem.
me: The database isn't the same. Test environments don't have a full
production load or, if they do, it's not up to date.
SG: Let them figure it out. I'm not a programmer.
Doug Scott
Nice explanation :-)
I wonder what the guy was thinking when he dreamt that up. And no, I
don't think I'd like to smoke what he's been smoking.
---
Doug
Doug Scott
> Let them figure it out. I'm not a programme
ROFL!
That whole sorry tale is a classic! And I'm sure it happens all over
the world.
---
Doug
LX-i
>
> Having worked on IBM mainframes for over 20 years, I've seen COND and
> how bad it can be. Sorry, COND can only be used to check for a return
> code from a prior step or if a prior step has abended. The problem with
> COND is that it's bass-ackwards of what you would think would happen...
>
> If you've never seen it, typical use (overly simplified to save space)
> is this...
>
> //A EXEC PGM=AAA123
> /*
> //B EXEC PGM=XYZ456,COND=(12,GT,A)
> /*
>
> Now program AAA123 can set a return code (a value in register 15) just
> prior to exiting and step B will examine the value.
>
> If A returns a return code of, say, 10...then the expression is "is 12
> greater than 10?", then the condition is evaluated as TRUE and (here's
> where it's bass-ackwards), step B is BYPASSED (program XYZ456 is NOT
> executed)!!!
>
> If A returns a return code of, say, 14...then the condition is evaluated
> as FALSE and the step B (program XYZ456) is EXECUTED!!
>
> You think it's bad with one code, try it with multiple codes from
> multiple steps!! Yech!!
I've recently gotten into some more complex ECL (Executive Control
Language, on the Unisys 2200-style mainframes), and their test condition
is the same - it seems backwards from the way the 3GL languages do
If/Else constructs. I still don't have a good enough grasp of it
(without the manual at my fingertips) to throw together a little example
here...
Thanks for the explanation!
Clark F. Morris, Jr.
> Lawrence,
>
> Nice explanation :-)
>
> I wonder what the guy was thinking when he dreamt that up. And no, I
> don't think I'd like to smoke what he's been smoking.
I think it was done by someone comfortable with NAND (not and) and NOR
(not or) gates. Unix also has its convolutions. That said, I agree
that COND was an abomination that never should have seen the light of day.
>
> ---
>
> Doug
>
> dws...@ieee.org
>
>
Joe Zitzelberger
JCL is completely declarative. All IF and COND logic is syntax checked
before execution begins. Then, the only alterable variable is the
return code of each step -- set after execution of said step is complete.
in the case above, myVAR will always be resolved prior to any step
executing. The only way it could be different is if the negated
condition tried to resolve the return code for the first step.
However, such a construct could not be built going from COND to IF.
JCL is one of those places where IBM shows its age. Imagine computing
of the early 60's -- then imagine JCL. They will be the same.
Joe Zitzelberger
Robert Wagner <rob...@wagner.net.yourmammaharvests> wrote:
> On Sat, 21 Aug 2004 10:01:08 -0400, "Don Leahy"
> <leah...@nospamplease.netscape.net> wrote:
>
> >Yes, but JCL isn't the only scripting language on z/OS. Complex scripts
> >can easily be handled through TSO Rexx.
>
> In the case of batch, Rexx writes the JCL and CA-7 executes it.
> Running production programs running under Rexx is not in the culture.
Rexx is useful -- but more as a replacement for CLIST that as a
replacement for JCL.
There are some nice things about JCL. The declaritiveness of it allows
for repeatable, predictable, production runs without the iffy-ness that
can show up from using a full-featured language for your scripts.
(For example, a commonly used Rexx function might be changed to have
subtle side-effects in production jobs -- JCL provides exactly what is
request or a error.)
Finally, you can't run Rexx without JCL*, so your are still somewhat
dependant upon some of its problems and oddities.
* Yes, yes, you could run it under CICS, but the you have the oddities
of CICS and JCL to deal with. Oh, you could run it under USS, but the
you have the oddities of USS and JCL to deal with. Well, you could run
it from a master console -- but that would be very strange...
Doug Scott
> I think it was done by someone comfortable with NAND (not and) and NOR
> (not or) gates.
Yes, I got that far in understanding it. It's obviously a hardware
engineer who invented it. What I can't understand how - even back in the
sixties - how anyone else could accept and adopt it. I know we had some
weird languages around at the time, but Sheesh! It's worse than RPG!
---
Doug
Doug Scott
> JCL is one of those places where IBM shows its age. Imagine computing
> of the early 60's -- then imagine JCL. They will be the same.
Unfair. I was working with computers in the sixties, and JCL was
incomprehensible from the day it came out. If you want to know the state
of the art back then, you'd also need to consider Algol (which became
Pascal).
But that wasn't IBM.
---
Doug
Chuck Stevens
"Doug Scott" <dws...@ieee.org> wrote in message
news:VA.0000072...@ieee.org...
> If you want to know the state
> of the art back then, you'd also need to consider Algol (which became
> Pascal).
While ALGOL may have *spawned* or even *inspired* Pascal, it didn't *become*
Pascal. There are five different dialects of ALGOL ("base" ALGOL,
BDMSALGOL, DMALGOL, DCALGOL and NEWP) and two of Pascal (Pascal, available
to customers, and Pascal83, used for internal products but so far as I know
unavailable to users) in the Unisys MCP environment today. NEWP includes
some features of Pascal not available in the ALGOLs (most notably enumerated
types).
> But that wasn't IBM.
Still isn't, so far as I know. ;-)
WFL is ALGOL-based as well; some users think it's rather easier to use and
more powerful than JCL is, or was ...
-Chuck Stevens
Doug Scott
> While ALGOL may have *spawned* or even *inspired* Pascal, it didn't *become*
> Pascal.
It's called "poetic license". It's the precursor of all block-structured
languages.
> two of Pascal
You've heard of Borland's Turbo Pascal, aka Delphi, I presume? Again, not pure
Pascal, but a stronger (IMHO) derivative.
Burroughs went heavily for Pascal-type languages in its systems languages, so
I'm not surprised that MCP still honours that tradition. I must admit that I
didn't know MCP had survived.
> WFL is ALGOL-based as well; some users think it's rather easier to use and
> more powerful than JCL is, or was ...
WFL? Anyway ANYTHING is easier to use and more powerful than JCL.
---
Doug
Chuck Stevens
news:VA.0000072...@ieee.org...
> You've heard of Borland's Turbo Pascal, aka Delphi, I presume? Again, not
pure
> Pascal, but a stronger (IMHO) derivative.
Yes, I have.
> Burroughs went heavily for Pascal-type languages in its systems languages,
so
> I'm not surprised that MCP still honours that tradition.
I think you've got the timing wrong.
Burroughs went heavily for block-structured languages, specifically in the
form of an extended version of ALGOL-60, a decade or more before Wirth
developed the first Pascal specification. The Burroughs B5000 and its
descendants have been honoring that decision, and that dialect, since their
introduction in 1961. Wirth didn't develop his Pascal specification until
1971.
While it can be argued that the Unisys MCP-based systems honor the
*contributions of Wirth* because of his contributions to ALGOL-60, it is
anachronistic to say that ALGOL is "Pascal-like" and that therefore MCP
honors the tradition of Pascal-type languages. It is as anachronistic as to
indicate that Unisys MCP systems honor the traditions established by PL/1 or
ADA by using an ALGOL-60 dialect, or that the music of J. S. Bach owes much
to the compositions of Felix Mendelssohn.
> WFL?
"Work Flow Language". A block-structured language introduced with the
B5000 in 1961.
-Chuck Stevens
Joe Zitzelberger
features that IBM should have added about the time they went from paper
tape to punch cards. And even more features that should have shown up
when direct access devices became common.
But all IBM ever did was add an IF statement and say 'use Rexx if you
want something else'...
In article <VA.0000072...@ieee.org>,
Paul Knudsen
<donts...@whydoyouneedmyaddressspammers.com> wrote:
>Really, IMO, I think COND is a complete nightmare. Probably more
>relatable to those with assembly experience, though. But a
>counterintuitive nightmare for those of us who don't.
What's Assembler got to do with it? I don't do assembler, but I
managed to master COND back when with a bit of careful study. If you
can't, hire someone who can.
--
Top 10 Conservative Idiots:
http://www.democraticunderground.com/top10/
Richard
> > If you want to know the state
> > of the art back then, you'd also need to consider Algol (which became
> > Pascal).
>
> While ALGOL may have *spawned* or even *inspired* Pascal, it didn't *become*
> Pascal.
There was a request for proposals for what was to be Algol-68.
Various different proposals were made including what Wirth called
Algol-W (and also such things as RRE's Alogol-68R). Wirth later
renamed his language as Pascal.
Of course Algol-W never was 'Algol' or 'Algol-68'.
Doug Scott
> it is
> anachronistic to say that ALGOL is "Pascal-like" and that therefore MCP
> honors the tradition of Pascal-type languages.
Sigh. Did I say that? I might have said that the Burroughs stuff was based on
Algol-type languages. I know very well that Pascal derives loosely from Algol.
> It is as anachronistic as to
> indicate that Unisys MCP systems honor the traditions established by PL/1 or
> ADA by using an ALGOL-60 dialect, or that the music of J. S. Bach owes much
> to the compositions of Felix Mendelssohn.
What planet are you from? Algol was the beginning. There were many
derivatives, including Pascal and MCP (so I'm told). It would be stretching
things to say that PL/I was derived from Algol - it merely borrowed a few
constructs.
---
Doug
Doug Scott
> I don't think JCL is incomprehensible -- just lame.
:-) OK. Lame it is.
> It lacks obvious
> features that IBM should have added about the time they went from paper
> tape to punch cards.
??? IBM were never into Paper tape. They ALSO supported paper tape, as
80-column images. They had too much invested in punched card machinery -
in fact, that's what held up the development of IBM computers - Thomas J
could foresee that computers could signal the end of punched cards.
> But all IBM ever did was add an IF statement and say 'use Rexx if you
> want something else'...
Wel, that's advancing a lot of years. REXX is a fine language. The best
thing I like about it is that the author threw away the rule book on
syntax/semantics, and implemented intuitive constructs.
---
Doug
Chuck Stevens
> > anachronistic to say that ALGOL is "Pascal-like" and that therefore MCP
> > honors the tradition of Pascal-type languages.
>
> Sigh. Did I say that? I might have said that the Burroughs stuff was based
on
> Algol-type languages.
What you wrote was "Burroughs went heavy for Pascal-like languages, so I'm
not surprised that MCP still honours that tradition." Unisys MCP is not
"honoring the traditions" established by Pascal-like languages for the same
reason that Bach didn't honor the traditions established by Mendelssohn.
> I know very well that Pascal derives loosely from Algol.
Not all that loosely, by what I read in the historical record!
> ... Algol was the beginning. There were many
> derivatives, including Pascal and MCP (so I'm told).
MCP is not a *derivative of* ALGOL, it is *written in* a derivative of ALGOL
(NEWP).
> It would be stretching
> things to say that PL/I was derived from Algol - it merely borrowed a few
> constructs.
I think the basic block/procedure structure of PL/1 did more than "borrow a
few constructs" from ALGOL. From what I can tell, the language can
simplistically be characterized as a synthesis of the block structure and
loop-control mechanisms of ALGOL with the record declaration capabilities of
COBOL, while keeping a side-glance at the FORTRAN application. All things
to all people. Such the 1968-vintage language spec from IBM I have at hand
leads me to believe, anyway.
-Chuck Stevens
William M. Klein
A) In any currently supported "mainframe" environment, (i.e. LE is available)
see CEE3ABD at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea3140/3.5.1
B) for pre-LE environments, see; ILBOABN0 at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igya1101/3.15.1
None of this requires C functions (or even z/OS, MVS, whatever, service calls)
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <rob...@wagner.net.yourmammaharvests> wrote in message
news:i8jhi0lnnfq33io49...@4ax.com...
Richard Steiner
"Chuck Stevens" <charles...@unisys.com> spake unto us, saying:
>WFL is ALGOL-based as well; some users think it's rather easier to use and
>more powerful than JCL is, or was ...
I really liked what I saw of WFL when I played with it for a few months
at a client site. Seems like a fairly flexible job control language.
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) seeking employment.
See web site above for resume/CV and background.
Richard Steiner
>I've recently gotten into some more complex ECL (Executive Control
>Language, on the Unisys 2200-style mainframes), and their test condition
>is the same - it seems backwards from the way the 3GL languages do
>If/Else constructs. I still don't have a good enough grasp of it
>(without the manual at my fingertips) to throw together a little example
>here...
That's one of the reasons I tended to use CALL macros for my own stuff
(with bits of ECL embedded in appropriate places as needed) instead of
using vanilla ECL runstreams. It's a very powerful option.
Here's a little CALL code snippet as an example:
if option('S') then
write '@fjtb';
if parameter(1) = '' then
write 'COPY FLT::FLT*SYSERRSUMMRY.,FLT*SYSERRSUMMRY.,DDP';
else
write 'COPY FLT::FLT*SYSERRSUMMRY(-'||parameter(1)||
').,FLT*SYSERRSUMMRY.,DDP';
endif;
write '@eof';
write '@copy,i flt*syserrsummry.,flt*syserr.'||start_date;
write '@eof';
if parameter(1) = '' then
print 'FLT*SYSERRSUMMRY from FLT will be copied to FLT*SYSERR.'
||start_date;
else
print 'FLT*SYSERRSUMMRY(-'||parameter(1)||'). from FLT will be'
||' copied to FLT*SYSERR.'||start_date;
endif;
endif;
if not option('X') then
print 'Note: Combined report has been written to '||
'TPF$.CONSCHK/REPORT';
query test1 with 'Do you want to view the full report (y/N)?';
if test1 = 'Y' or test1 = 'y' then
if total_lines > 23 then
write '@cshell*cshell.more tpf$.conschk/report';
else
write '@eof';
endif;
endif;
endif;
If you've ever used OS2200 command-line tools like UEDIT, FINDREF, or
CSHELL, this is the macro language they are written in. FWIW.
Robert Wagner
<wmk...@nospam.netcom.com> wrote:
>The answer of how to "ABEND" from a COBOL program:
>
>A) In any currently supported "mainframe" environment, (i.e. LE is available)
>see CEE3ABD at:
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea3140/3.5.1
>
>B) for pre-LE environments, see; ILBOABN0 at:
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igya1101/3.15.1
>
>None of this requires C functions (or even z/OS, MVS, whatever, service calls)
Next time I want to abend a Unix program I'll do a Remote Procedure
Call to a mainframe.
Glenn Someone
While both are elementally "Pascal" in the language sense, Delphi
changed the language constructs to the point that Delphi could be
considered a descendent of Turbo Pascal and therefore technically a
different language with different skill sets. While someone versed in
Delphi could go and use Turbo Pascal with very little adjustment,
someone versed in Turbo Pascal would be comfortable with the syntax
conventions of Delphi, but would have to re-learn most of the standard
constructs.
On Mon, 23 Aug 2004 21:32:27 +0100, Doug Scott <dws...@ieee.org>
wrote:
>You've heard of Borland's Turbo Pascal, aka Delphi, I presume? Again, not pure
William M. Klein
service is available for that compiler. Micro Focus (for example) provides
"emulations" of the CEE callable services with some (not all) of their
compilers. IBM, of course, provides its own versions of many CEE callable
services with their AIX products.
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <rob...@wagner.net.yourmammaharvests> wrote in message
news:kvpoi05spu0odple6...@4ax.com...
Michael Wojcik
In article <VA.0000072...@ieee.org>, Doug Scott <dws...@ieee.org> writes:
>
> > WFL is ALGOL-based as well; some users think it's rather easier to use and
> > more powerful than JCL is, or was ...
>
> WFL? Anyway ANYTHING is easier to use and more powerful than JCL.
I submit that OS/400 CL is harder to use and less powerful than JCL,
despite being the only IBM-supplied "scripting" mechanism included
with the OS. At least for OS/400 V3 and earlier.
--
Michael Wojcik michael...@microfocus.com
This record comes with a coupon that wins you a trip around the world.
-- Pizzicato Five
james8049
In defense of JCL!
For its time JCL was quite advanced:
It give you device independence long before UNIX did. The target of a
DD statement could be a printer, cardreader, disk file, tape drive, a
collection of files. As long as it was readable for "OPEN INPUT" or
writeable for "OPEN OUTPUT" and some basic record size and blocking
matched your program did not care.
And if you think JCL is bad try UNIX CSH.
Having said that though the only JCL I ever use is:-
//TSO EXEC PGM=IKJEFT1B,.......
:-)
--
james8049
------------------------------------------------------------------------
Posted via http://www.codecomments.com
------------------------------------------------------------------------
Howard Brazee
On 24-Aug-2004, james8049 <james804...@mail.codecomments.com> wrote:
> In defense of JCL!
> For its time JCL was quite advanced:
> It give you device independence long before UNIX did. The target of a
> DD statement could be a printer, cardreader, disk file, tape drive, a
> collection of files. As long as it was readable for "OPEN INPUT" or
> writeable for "OPEN OUTPUT" and some basic record size and blocking
> matched your program did not care.
How do you compare JCL with what the other mainframe computer manufacturers
offered?
Let's pick a date - say 1980 and rank the various mainframe operating systems.
Or 1970.
Joe Zitzelberger
"Howard Brazee" <how...@brazee.net> wrote:
The only date that matters is 2004 -- no other mainframe OS/hardware
combos exist. It is JCL compared to bash or cmd.
My only complaint is that IBM has failed to realized that the tiny
computers are taking over its turf. If it does not update its tools to
be competitive it will go the way of ______________ (Rayovac, Spery, GE,
Univac, RCA, fill in the blank with the name of a dead electronics
manufacturer here, etc, etc)...
Richard Steiner
Joe Zitzelberger <joe_zitz...@nospam.com> spake unto us, saying:
>The only date that matters is 2004 -- no other mainframe OS/hardware
>combos exist. It is JCL compared to bash or cmd.
As a 2200 programmer who has at least an academic interest in IBM's
JCL, how does it compare to the current incarnation of Unisys' ECL?
Does anyone here know both?
>My only complaint is that IBM has failed to realized that the tiny
>computers are taking over its turf. If it does not update its tools to
>be competitive it will go the way of ______________ (Rayovac, Spery, GE,
>Univac, RCA, fill in the blank with the name of a dead electronics
>manufacturer here, etc, etc)...
You might want to note that at least two members of the BUNCH (Sperry
and Burroughs) are still very much alive in their limited markets under
the guise of Unisys "Clearpath" hardware (which run either OS2200/EXEC8
or MCP in most cases). :-)
Richard
> My only complaint is that IBM has failed to realized that the tiny
> computers are taking over its turf.
How odd that you think this. The number of z series machines being
sold is greater than ever before.
> If it does not update its tools to
> be competitive it will go the way of ______________ (Rayovac, Spery, GE,
> Univac, RCA, fill in the blank with the name of a dead electronics
> manufacturer here, etc, etc)...
Well it has 'updated'. Now most z series seem to be running Linux.
Robert Wagner
>Joe Zitzelberger <joe_zitz...@nospam.com> wrote
>
>> My only complaint is that IBM has failed to realized that the tiny
>> computers are taking over its turf.
>
>How odd that you think this. The number of z series machines being
>sold is greater than ever before.
Not ever before, since the late '80s. During the '90s IBM was selling
about 30 _new_ shops per year in the US. After they introduced Linux,
the number shot up to 200.
>> If it does not update its tools to
>> be competitive it will go the way of ______________ (Rayovac, Spery, GE,
>> Univac, RCA, fill in the blank with the name of a dead electronics
>> manufacturer here, etc, etc)...
Don't forget Amdahl and Cray, which are now sinking ships.
>Well it has 'updated'. Now most z series seem to be running Linux.
Make that most NEW installations. There are many more zOS shops in the
US. I've been told that in the world, VSE is still IBM's most popular
operating system.
FWIW, 70% of IBM's Net Profit still comes from mainframes. Not Revenue
but net profit. Most of it comes from non-hardware functions such as
Services (outsourcing, body-shop backfill) and Software licenses.
I've worked with their Services people quite a lot. I wasn't impressed
with their screening standards. Other contracting companies cultivate
long-term relationships. With IBM, workers are a commodity to be
herded in and out. Some of their people, mostly managers, are
talented, but 90% are cordwood. Clients could hire better talent from
other contractors for less than half IBM's $200/hr bill rate. For some
reason, the IBM imprimatur continues to have cachet and command
respect from executives.
Not because it's Good but because it's Safe. If a project fails, it's
finger-pointing time. Nobody can criticize the decision to go with the
Gold Standard IBM. Similarly, networking contracts go to AT&T, not
because they have the best talent, but because they're The Phone
Company.
We've developed a mentality that reveres Brand Names as safe havens,
fulfilling the function religion used to perform. Then you were
Protestant, Catholic or Jewish; later you were GM, Ford or Chrysler;
now you are IBM, Sun or Mac. Human nature doesn't change. IBM found
a way to exploit that and it continues to pay dividends 25 years
later.
docd...@panix.com
Robert Wagner <rob...@wagner.net.yourmammaharvests> wrote:
[snip]
>For some
>reason, the IBM imprimatur continues to have cachet and command
>respect from executives.
>
>Not because it's Good but because it's Safe. If a project fails, it's
>finger-pointing time. Nobody can criticize the decision to go with the
>Gold Standard IBM.
As my first programming instructor taught us, lo, those many years ago,
'Nobody ever got fired for recommending IBM'.
As the Germans say, 'plus ca change, plus c'est la meme chose'.
DD
Robert Wagner
>As the Germans say, 'plus ca change, plus c'est la meme chose'.
Germans wouldn't phrase their aphorisms in French. Too close to home.
Maybe Brazilian Portuguese or Spanish .. to show how worldly they are.
docd...@panix.com
Mr Wagner, I've worked with Germans... and my experience is different than
what you describe here.
DD
Joe Zitzelberger
Robert Wagner <rob...@wagner.net.yourmammaharvests> wrote:
Perhaps it was said by an ex-collaborator with an original native French
language.
;-)
steve
you? I'd like to contact someone else out there who is using this
stuff.
Steve
LX-i <lxi...@netscape.net> wrote in message news:<Nq8Wc.29087$5s3....@fe40.usenetserver.com>...
> Lawrence H Greenwald wrote:
> >
> > Having worked on IBM mainframes for over 20 years, I've seen COND and
> > how bad it can be. Sorry, COND can only be used to check for a return
> > code from a prior step or if a prior step has abended. The problem with
> > COND is that it's bass-ackwards of what you would think would happen...
> >
> > If you've never seen it, typical use (overly simplified to save space)
> > is this...
> >
> > //A EXEC PGM=AAA123
> > /*
> > //B EXEC PGM=XYZ456,COND=(12,GT,A)
> > /*
> >
> > Now program AAA123 can set a return code (a value in register 15) just
> > prior to exiting and step B will examine the value.
> >
> > If A returns a return code of, say, 10...then the expression is "is 12
> > greater than 10?", then the condition is evaluated as TRUE and (here's
> > where it's bass-ackwards), step B is BYPASSED (program XYZ456 is NOT
> > executed)!!!
> >
> > If A returns a return code of, say, 14...then the condition is evaluated
> > as FALSE and the step B (program XYZ456) is EXECUTED!!
> >
> > You think it's bad with one code, try it with multiple codes from
> > multiple steps!! Yech!!
>
> I've recently gotten into some more complex ECL (Executive Control
> Language, on the Unisys 2200-style mainframes), and their test condition
> is the same - it seems backwards from the way the 3GL languages do
> If/Else constructs. I still don't have a good enough grasp of it
> (without the manual at my fingertips) to throw together a little example
> here...
>
> Thanks for the explanation!
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~ / \ / ~ Live from Montgomery, AL! ~
> ~ / \/ o ~ ~
> ~ / /\ - | ~ LXi...@Netscape.net ~
> ~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> ~ I do not read e-mail at the above address ~
> ~ Please see website if you wish to contact me privately ~
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> ~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
> ~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
> ~ h---- r+++ z++++ ~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LX-i
> Hey! I have extensive experience in UNISYS 2200 ECL. Who and where are
> you? I'd like to contact someone else out there who is using this
> stuff.
Almost all the information you're after is either in my sig block, or
easily obtainable through it... :)
kprasann
program was actually migrated from mainframes and has a CALL to ILBOABN0
IBM routine.
Thanks,
Krish.
Michael Mattias
news:71345c8d9e1ad8ea...@localhost.talkaboutprogramming.com...
> Hello, I'm trying to abend a micro focus COBOL program in AIX. The COBOL
> program was actually migrated from mainframes and has a CALL to ILBOABN0
> IBM routine.
Why not exit gracefully instead? ABEND on mainframe is usually done to let
the operating system "roll back" all the data created in a JCL steam.
Of course, you *could* force an abnormal termination....
instead of CALL 'ILBOAAN0' you could...
DIVIDE X BY ZERO
MCM
steve.t
program do something else unexpected but does not "bomb"?
Later,
Steve.T
Robert Wagner
call 'abort' using return-code
It will do the same as STOP RUN unless you set other options, such as
the one controlling memory dump.
William M. Klein
existence of a CEE3ABD routine (which should be used on current mainframes
instead of ILBOABN0 anyway)
I am not certain if the AIX products do or don't have the LE callable routines
available.
--
Bill Klein
wmklein <at> ix.netcom.com
"kprasann" <ash...@rediffmail.com> wrote in message
news:71345c8d9e1ad8ea...@localhost.talkaboutprogramming.com...