Please Do My Job/Homework?
cory hamasaki
docd...@clark.net
cory hamasaki <kiy...@ibm.XOUT.net> wrote:
>On Fri, 19 Mar 1999 13:50:45, docd...@clark.net () wrote:
>
>> MQSeries for bouncing a full file? Strike me as a bit of overkill but I
>> am, of course, shaped by my experiences... and those have used IND$FILE or
>> ftp for moving *files* and MQ for bouncing around *transactions* (or, as
>> we used to call them, 'records'). Using MQ to move files around strikes
>> me as similar to driving 20-penny nails with a tack-hammer... sure, it
>> *can* be done but applying a different tool mightmake Life a bit Happier,
>> all around.
>
>MQSeries is a superior technical solution to either. MQSeries has
>subsumed file transfer. But then, you may believe in good enough.
Hmmmm... rather than debate the Fine Points of using a vendor-specific
mechanism as opposed to an 'open platform' one (MQ = IBM, ftp = everyone)
I will say 'Of course I admit to my ignorance, right up front... but would
you please be so kind as to point me towards documentation of the
assertions of MQ's 'technical superiority' and MQ's 'subsuming' other
methods... preferably documentation by a source *other* than the
International Business Machines Corporation?'
>
>> >Unlike DD, my OS/390 processing is handled, the jobs run fine now. I
>> >just have to get the data to them.
>>
>> The jobs 'run fine' but the data aren't there yet... a sure sign of Fun To
>> Come!
>
>I am replacing an MVS-OS/2 technical approach with a Un*x (on an
>E10K)-WindowsNT solution. Slower, less reliable, more costly but hey,
>you should see the services invoice.
Not to mention 'technically superior'... and remember DD's Law of
Well-Functioning Systems:
'A Well-Functioning System is one which causes the person who has say over
signing the checks for it to smile.'
>
>> Yow... uno momentitio, Mein Herr. My limited experience tells me that
>> IND$FILE and ftp *cannot* address DB2 databases; they are *strictly
>> flatfile tools. Once you manage to:
>>
>> put netwkfil.dat 'PRODSYS.NETWORK.FLATFILE.UPLOAD'
>
>we call it:
>
> send netwkfil.dat 'PRODSYS.NETWORK.FLATFILE.UPLOAD' ascii crlf
Allowing RECFM, LRECL and BLKSIZE to default? How daring!
>
>>
>> .... you are then, I would say, going to need to SUBmit a batch job to load
>> this file to DB2. If you are dealing with an 'All-ya-gotta-do-is' coder
>> then you'll have to write a standalone application which will READ an
>> inrec and then do an INSERT; if you're very, *very* lucky the programmer
>> who generated the application which created the PC-side file will have
>> generated it in the same 'image' as the DB2 table so that you can run it
>> through IKJEFT01.
>
>OS/390 runs a series of batch jobs now. The upload is only
>marginally flat file-ish. It includes multiple files, an embedded
>structure, this file points to those, those contain internal structures
>and so forth.
Oooo-weee an' skinny Minnie, sounds like someone's been eating Object
Oriented Crunchies and reading the back of the cereal-box!
[snippage of my tawdry past]
>One of the series of batch jobs is a database load program written in
>PL/I (X). We run at object code speed.
As I noted before i snipped it, you might want to check into redesigning
your load using IKJEFT01 should you begin to amass any considerable
amounts of data, say 3 - 5 million rows/load
>
>Our invocation of batch TSO runs a Rexx that parse-args its heart out,
>makes decisions, forms command strings, and runs FTP at object code
>speed.
>
>To the extent possible, we avoid JCL, even the Logic-JCL that
>you COBOL'ers find so fascinating.
Hey, wait a minute... someone else, a few posts back, mentioned a dearth
of IF structures in JCL even though the capability for them has existed
for the past decade and now you castigate the coders for finding them
'fascinating'? Be that as it may (the system I'm working on now is still
compiled with IKFCBL00) the closest I come to JCL logic is COND... and
that, as this thread shows, is bedevilling folks even unto this very day.
>Rexx provides better control
>structures, access to catalog and dsn information. We also use Rexx to
>write log and statistics files.
>
>The chain is: CA7 starts JCL; JCL starts IKJEFT01; TSO runs Rexx; Rexx
>looks around and decides; Rexx runs compiled code such as FTP. Depending
>upon how you have LPA set up, the cost in LINKLST and Page traffic is
>nominal.
>
>(Hey Lan-lord, feel free to jump right in. Brad, do you have Regina on
>your machines? )
>
>Even with FICON, IO is still a killer. IO costs. Even worse is
>programmer and production control analyst time.
Well... at least I try to adjust my hourly rate to make it so.
DD
cory hamasaki
docd...@clark.net
cory hamasaki <kiy...@ibm.XOUT.net> wrote:
>On Fri, 19 Mar 1999 16:10:07, docd...@clark.net () wrote:
>
>> Hmmmm... rather than debate the Fine Points of using a vendor-specific
>> mechanism as opposed to an 'open platform' one (MQ = IBM, ftp = everyone)
>> I will say 'Of course I admit to my ignorance, right up front... but would
>> you please be so kind as to point me towards documentation of the
>> assertions of MQ's 'technical superiority' and MQ's 'subsuming' other
>> methods... preferably documentation by a source *other* than the
>> International Business Machines Corporation?'
>
>MQSeries has been covered by both Technical Support Magazine and
>Enterprise Systems Journal, two independent mainframe publications.
... and did their coverage come to the conclusions you present?
>IBM has stated that MQSeries is an "Open Solution", whatever that means.
If IBM states it then it *must* be... something.
>
>> Allowing RECFM, LRECL and BLKSIZE to default? How daring!
>
>Very daring. These are human readable files. No binary data, blank
>delimited data designed to be processed by the Rexx Parse clause.
I assume by 'blank' you mean what COBOL-jockies call 'SPACES', or x'40'...
no names or addresses in these files, then.
>
>> Oooo-weee an' skinny Minnie, sounds like someone's been eating Object
>
>skinny Minnie? You be hangin' with ho's now?
Perhaps, Mr Hamasaki, you might be made aware of the limited circles which
will accept the presence of COBOL-codin' fools.
>
>> Oriented Crunchies and reading the back of the cereal-box!
>
>or new age programmers?
I did not know there was a difference.
>
>> As I noted before i snipped it, you might want to check into redesigning
>> your load using IKJEFT01 should you begin to amass any considerable
>> amounts of data, say 3 - 5 million rows/load
>
>You might mull things over before snipping yourself, DD. The TSO
>and Rexx overhead is only paid once. Take a look at the "Address"
>clause. Once we pass control to native S/390 object code, we run at
>native S/390 object code speeds.
TSO and Rexx overhead is one thing.. IO algorithms are another. SyncSort,
for example, does things *much* more efficiently than, say, MVS BASIC and
I am assuming - rightfully or wrongly - that such a thing is at work when
IKJEFT01 moves faster than a COBOL program does. Both are doing the same
thing - READ an inrec, INSERT it into a table-row, all IO, nothing more -
so I conclude that the IO subroutines included into the LM generated by
HEWL from the object code generated by IKFCBL00/IGYCRCTL are less
efficient than those used by IKJEFT01... if this assumption or conclusion,
based as both most obviously are, in conjecture, ignorance and overall
cogitative sloth, are incorrect, then be so kind as to point out where the
error was generated.
>
>> Hey, wait a minute... someone else, a few posts back, mentioned a dearth
>> of IF structures in JCL even though the capability for them has existed
>> for the past decade and now you castigate the coders for finding them
>> 'fascinating'? Be that as it may (the system I'm working on now is still
>> compiled with IKFCBL00) the closest I come to JCL logic is COND... and
>> that, as this thread shows, is bedevilling folks even unto this very day.
>
>Castigate? I would have thought that those who use a language with
>"subtract .... from ... giving ... " would feel right at home saying "Do
>not excute this step if 4 is less than the return code from a previous
>stepname."
A good thing that you 'would have thought', rather than 'did think', as
the result would have been your being WRONG... yet again. Get out of your
frangipani-wrapped bedrool and sniff around some *real* shops - insurance,
manufacturing, utility billing - and see how these 'newfangled' features a
mere decade old are scorned.
>Other may prefer programming languages with more modern
>constructs.
Others may, sure... but let them *try* to get some code past a review and
implemented into Prod!
'What is *this* stuff? EVALUATE TRUE WHEN cond-1 imperative statement...
you call this COBOL?!?'
'Oh, please, Mr Standards-and-Practises Reviewmeister, it is exactly what
is allowed by the ANSI '85 Standard.'
'ANSI '85? Crap, I *knew* things were goin' ta hell in a handbasket when
we allowed them fancy ANSI '74 constructs in a couple a' years back...
look, 1985 is only 14 years ago, we oughta wait until the technology is
Really Proven before we implement it. Go back and rewrite this in *real*
COBOL, then try again.'
>
>> Well... at least I try to adjust my hourly rate to make it so.
>
>It's almost that time isn't it?
It is *always* that time, Mr Hamasaki.
DD
cory hamasaki
The Goobers
>
> On Fri, 19 Mar 1999 20:41:42, docd...@clark.net () wrote:
>
> > .... and did their coverage come to the conclusions you present?
>
> I recall glowing reviews of MQSeries by both.
A glowing review can be written of a night-light, Mr Hamasaki; it is one
thing to write a 'glowing review' about a product and quite another to
say that said product is 'a superior technical solution' or 'subsumes'
another... but you knew that already, didn't you?
>
> > I assume by 'blank' you mean what COBOL-jockies call 'SPACES', or x'40'...
> > no names or addresses in these files, then.
>
> By names, I presume you mean in the "by name" sense. If so, you do
> understand that a name is an address.
No, I mean a names like Johann Sebastian Bach, to mention only a few,
and addresses such as 123 Dutch Elm St (5A Front). Were your file to
contain such Mundanities of Data Processing as these you'd have found
your... decidedly unspare gluteals beset-upon by the Teeth of Imbedded
Spaces. COBOL-codin' fools know about such things, having been
requested to properly parse strings like Sir Joseph Porter, KQB, LlD MD,
QBVII TANSTAAFL into
TITL PIC X(03).
FNAM PIC X(10).
MI PIC X(01).
LNAM PIC X(15).
HONRFC OCCURS 1 TO 5 DEPENDING ON HRN-SUB PIC X(05).
... and sometimes even managed to do it, too.
>
> > Perhaps, Mr Hamasaki, you might be made aware of the limited circles which
> > will accept the presence of COBOL-codin' fools.
>
> Are not all welcome at the table?
I do not think it would be wise to test that question by expanding the
cross-posting headers to include comp.lang.c.
>
> > TSO and Rexx overhead is one thing.. IO algorithms are another. SyncSort,
> > for example, does things *much* more efficiently than, say, MVS BASIC and
> > I am assuming - rightfully or wrongly - that such a thing is at work when
> > IKJEFT01 moves faster than a COBOL program does. Both are doing the same
> > thing - READ an inrec, INSERT it into a table-row, all IO, nothing more -
> > so I conclude that the IO subroutines included into the LM generated by
> > HEWL from the object code generated by IKFCBL00/IGYCRCTL are less
> > efficient than those used by IKJEFT01... if this assumption or conclusion,
> > based as both most obviously are, in conjecture, ignorance and overall
> > cogitative sloth, are incorrect, then be so kind as to point out where the
> > error was generated.
>
> Avert your eyes Lan-Lord, DD is getting Down and Dirty.
(or as best as an Applications Coder might hope to attempt such)
>
> IKJEFT01 as I recall from the last time I saw the source code, uses a
> direct LINK to pass control to command processors. At one time it did a
> BLDL followed by a LOAD. This was APAR'ed by someone, I suspect American
> Airlines. ...but I'm just nattering here.
So I noticed... happens with age, I'm told, so what's *your* excuse, ya
blithering... oh, wait, maybe something better will come.
>
> IKJEFT01 has nothing to do with your database load, it's the TMP, its
> job is to GETLINE the command line, call IKJSCAN, construct the CPPL and
> LINK to the command processors. Along the way, it chats with various
> exits, issues SPIE's and STAE's and such. It's main job is to say
> "READY"
zzzzZZZZZzzzzzzz... and once again it is demonstrated that 'maybe' is...
exactly that.
>
> If database loads are running slow, it's an installation tuning or policy
> issue. Once control is passed to the problem state program, it should
> run at native speeds.
Ye Gods and Little Fishies, man, hae ye nawt heerd... a-HEM, have you
not been listening to anything? The difficulty is not 'slow database
loads', it is the disparity in the speed of such a task as performed by
two different mechanism, a COBOL program and IKJEFT01. To re-state: one
has a flat-file and a DB2 database (which is, of course, nothing but a
glorified collection of VASM files... but more on that another time).
To make it even easier the file is sorted on the database's index. A
JCL invocation of IKJEFT01 will LOAD that file into the database in no
time at all, hey presto! A COBOL program which purports to do exactly
the same thing - READ a rec, INSERT a row - will run until the next IPL.
*I* say that this is because the IO subroutines invoked by the COBOL
program - said invocation being the result of the ILB0/IGZE subroutines
- behave in a fundamentally differently and less efficient manner than
do those used by IKJEFT01. Is this assumption I make and the conclusion
to which I arrive in accord or discord with hard-wired, patch-corded
world so beloved of folks who are so enamored by the architecture that
they forget that the machine is actually there in order to run
applications?
(note to neophytes: the last sentence of the above paragraph points out
a fundamental discrepancy in the approaches taken to computer
architectures by Applications Programmers - whom I, at present and
completely unelected, represent - and Systems Programmers - represented
by Mr Hamasaki at his... usual level of quality. Systems Jockies have a
dream of the Ultimate Machine as one which is zipping long at an
infinitely great number of instructions or floating-point operations per
unit time with *no transcation load whatsoever*... while Application
Coders realise that *in spite of* the wizardry and mumbo-jumbo behind it
the computer is actually there To Do A Job)
>
> Some of us have mixed feelings about Syncsort. Long CCW chains and
> dynamic modification of CCWs, page fixing, EXCPVR, sure it runs well but
> we have other users on the system.
Then those of you with such reservations can prevail on the RACF Lords
to restrict Control Interval access to a select group of UIDs and force
the Untrustworthy Masses to specify PARM=NOCINV... this is, however,
*almost* tangential to the question I asked about different IO methods.
SyncSort can be directed to CINV or NOCINV access, a COBOL program (to
the best of my knowledge) cannot. Since SyncSort can be directed in a
manner unlike a COBOL program I conclude that SyncSort makes use of IO
subroutines which are not available to/addressable the COBOL program.
Be this so, or no?
>
> We want nicely behaved applications, BLKSIZEs matching pagesizes, a
> reasonable number of buffers, intelligent use of VIO; we don't like
> applications that get funny ideas, get upity and start acting out.
If you want it that way then set up Structures and Procedures in order
to do it that way; such things are not so well-defined that even The
Experts all agree with each other with each other.
>
> If Rexx calls COBOL (or FTP), Rexx doesn't introduce any IO cost. Its
> memory might have to be paged under some conditions but if so, your
> shop is running memory constrained.
But... if Rexx is calls COBOL, and COBOL does a WRITE, then the WRITE is
attended to by an IGZE subroutine. If Rexx does its *own* WRITE... what
attends to it in a similar manner?
>
> > 'What is *this* stuff? EVALUATE TRUE WHEN cond-1 imperative statement...
> > you call this COBOL?!?'
> >
> > 'Oh, please, Mr Standards-and-Practises Reviewmeister, it is exactly what
> > is allowed by the ANSI '85 Standard.'
> >
> > 'ANSI '85? Crap, I *knew* things were goin' ta hell in a handbasket when
> > we allowed them fancy ANSI '74 constructs in a couple a' years back...
> > look, 1985 is only 14 years ago, we oughta wait until the technology is
> > Really Proven before we implement it. Go back and rewrite this in *real*
> > COBOL, then try again.'
>
> Oh my. Doing a lot of Perform'ing are you?
As does any Decent Programmer who has learned to abide the rules of
Modified Yourdon Structured Programming as taught by McCracken... oh, I
apologise, I forgot that the knowledge, habits and practises of Decent
Programmers might be alien to System Jockies.
>
> > It is *always* that time, Mr Hamasaki.
> >
> > DD
>
> Time, there's that word. It's gone. No time left.
Then if there's no time left what remains must be the right time, neh?
DD
Frank Ney
docd...@clark.net () to write:
>>> Oooo-weee an' skinny Minnie, sounds like someone's been eating Object
>>
>>skinny Minnie? You be hangin' with ho's now?
>
>Perhaps, Mr Hamasaki, you might be made aware of the limited circles which
>will accept the presence of COBOL-codin' fools.
That's why I started hanging out at the race track. <g>
Frank Ney N4ZHG WV/EMT-B LPWV NRA(L) GOA CCRKBA JPFO
Fan Guest of Honor, Technicon 16 http://www.technicon.org
--
"America is at that awkward stage. It's too late to work within
the system, but too early to shoot the bastards. On the road to
tyranny, we've gone so far that polite political action is about
as useless as a miniskirt in a convent."
- Claire Wolfe, _101 Things To Do 'Til The Revolution_
docd...@clark.net
Frank Ney <cro...@barkingmad.org> wrote:
>On 19 Mar 1999 20:41:42 GMT, an orbiting mind control laser caused
>docd...@clark.net () to write:
>
>>>> Oooo-weee an' skinny Minnie, sounds like someone's been eating Object
>>>
>>>skinny Minnie? You be hangin' with ho's now?
>>
>>Perhaps, Mr Hamasaki, you might be made aware of the limited circles which
>>will accept the presence of COBOL-codin' fools.
>
>That's why I started hanging out at the race track. <g>
One of the *other* venues which welcomes the two-dollar bill, it seems.
DD
Shmuel (Seymour J.) Metz
> TSO and Rexx overhead is one thing.. IO algorithms are another. SyncSort,
> for example, does things *much* more efficiently than, say, MVS BASIC and
> I am assuming - rightfully or wrongly - that such a thing is at work when
> IKJEFT01 moves faster than a COBOL program does. Both are doing the same
> thing - READ an inrec, INSERT it into a table-row, all IO, nothing more -
> so I conclude that the IO subroutines included into the LM generated by
> HEWL from the object code generated by IKFCBL00/IGYCRCTL are less
> efficient than those used by IKJEFT01... if this assumption or conclusion,
> based as both most obviously are, in conjecture, ignorance and overall
> cogitative sloth, are incorrect, then be so kind as to point out where the
> error was generated.
Obviously, the error was generated in the standard aristotelian fashion:
make assumptions, don't bother to verify the assumptions against
observations of reality, then proceed to derive incorrect inferences
from those data with perfectly valid reasoning (or invalid reasoning -
it works either way.)
> >Other may prefer programming languages with more modern
> >constructs.
>
> Others may, sure... but let them *try* to get some code past a review and
> implemented into Prod!
Ha, reminds me of the time that I was tasked with writing several
related reports from the same data. Rather than writing several similar
programs, I wrote a single data directed program, and then had to
explain to the customer what data directed programming was all about. I
was finally allowed to deliver the code as written, but it taught me a
valuable lesson about the propagation speed of "state of the art",
including things that "everybody understands by this time."
--
Shmuel (Seymour J.) Metz
Reply to host nsf (dot) gov, user smetz