Please Do My Job/Homework?
docd...@clark.net
Alright, gang.. I've got a moderately juicy one upon which I would
appreciate a modicum of assistance.
What I've been doing lately is only tangentially COBOL-related... but it
beats the heck outta Y2K remediation for holding my interest! The company
I've contracted with has Stuff 'n Processing on the mainframe and Stuff 'n
Processing on the PC (actually networked NTs) and data need to be bounced
from one to the other. I've set up a series of four mechanisms which
kinda sorta maybe boil down to these steps:
The geepo in the warehouse figures 'Hey, time to download the latest set
of orders that were entered on the mainframe!'... and double-clicks on an
icon I've set up for this purpose.
The icon invokes a batch file.
The batch file deletes the previous-previous order file, renames the
previous order file 'OldOrd' (or something like that) and invokes ftp
using the -s option and the mainframe's IP address as the target.
The file specified by the -s option logs onto the mainframe and submits a
job to the internal reader.
The job submitted to the internal reader executes a proc (one of those
plain ol' proc-type procs, in SYS.PROD.PROCLIB)
The executed proc consists of two steps: an IEFBR14 (don't ask me why but
the guys in Ops said this 'dummy step' was necessary) and an invocation of
UCC7 (PGM=U7SVC)... and the PARM of this invocation specifies some JCL
which UCC7 is supposed to submit.
(note: this is done so a record of the JCL's run will be kept by UCC7)
The JCL submitted by the invocation of UCC7 by the proc executed by the
JCL submitted to the internal reader by the ftp invoked by the batch file
executed by the operator's clicking on the NT icon (still with me so far?)
invokes another proc which does the actual work... for the sake of clarity
I'll call this proc FRED.
FRED, at heart, consists of two steps... a COBOL job (which I wrote... see
where the 'lang.cobol' fits in?) and another ftp. The COBOL job runs
against the mainframe databases (DataComm), extracts the orders that the
warehouse-gang needs and dumps these to a flat-file. The flat-file is
then ftp'd by the next step back down to the PC so the warehouse crew can
take care of their own jobs.
Now that I've explained all that I can get to the guts of my request. The
ftp step in the proc FRED uses a standard sort of SYSIN member from
SYS.PROD.CARDLIB. This member directs the ftp to the target system... in
this case, the IP address of the NT workstation which originated the
request.
The latest installation I'm working on has *2* NT workstations, Primary
and Backup. Under normal circumstances everything goes to Primary, of
course... but when (*not* 'if', 'when') the Primary drops the Backup gets
used. Everything about the processing initiated by either Primary or
Backup is identical EXCEPT... except for the one line in the CARD member
which directs the mainframe ftp back to the originating workstation. In
other words, when Primary is used the first line of the CARD member will
be, say, 100.100.100.101 (Primary's IP address) and when Backup is used
this needs to be 100.100.100.102.
I'm looking for as elegant a way to deal with this as possible. The most
ready solution would be to have two versions of FRED, FREDPRIM and
FREDBACK, and the only difference between the two would be in the SYSIN
for the ftp step.. FREDA would pull in SYS.PROD.CARDLIB(FTPPRIM), FREDB
would pull in SYS.PROD.CARDLIB(FTPBACK) and the only difference in these
CARD members would be the IP address mentioned above.
The more elegant solution would be to be able to supply, via override,
either the DD for the ftp step in FRED or the suffix of the member-name
via symbolic... but I'm not sure if such a thing can be preserved through
the layer upon layer of JCL and proc and UCC7 and JCL and proc that I've
described.
Any suggestions?
DD
Ted Hoffman
But couldn't you also have the NT ftp the SYSIN card
for FRED, identifying itself with its own IP address?
Hoffmeister
**** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ****
Don Scott
>
>Any suggestions?
>
>DD
The obvious, simple solution is to double-FTP the work-orders *every*
time to both Primary and Backup.
The more exciting way to do it, of course, is to have the COBOL
program dynamically create the SYSIN (or whatever) for the FTP process
so that it ftp's to either xxx.xxx.xxx.ppp or xxx.xxx.xxx.bbb.
Going that way, you somehow have to signal to the COBOL program that
it's either .ppp or .bbb at this moment in time. That can be done a
number of ways, but maybe you can append something to the "request"
file that identifies the requestor as the Primary or the Backup.
OR, maybe you can make it work *anywhere* by having the requestor
machine submit its IP address along with the request, and then the
COBOL program can dynamically create the ftp SYSIN (or whatever) to
ftp the results to the requestor's IP, whether that be Primary, Backup
or Joe's Machine in the Corner.
DS
docd...@clark.net
Ted Hoffman <hoff_m...@my-dejanews.com> wrote:
>My JCL..very bad.
>
>But couldn't you also have the NT ftp the SYSIN card
>for FRED, identifying itself with its own IP address?
Yes... and no. The reason that the SYSIN cards are kept on the mainframe
to begin with is to centralise maitainability; the JCL which is ftp'd from
the NT is to be kept to a bare minimum, e.g.,
//JOBNAM01 JOB (P777,X888),'SITENAME - ORD DLOAD',CLASS=B,MSGCLASS=R,
// NOTIFY=XXXXXXX,MSGLEVEL=(1,1)
/*ROUTE PRINT R99
//STEP001 EXEC UCC7SUB1
... or, more-or-less, a jobcard and an EXEC for the proc which invokes
UCC7. This is done so that there's as little jiggering-about which might
be needed on the PC.
Now it *might* be possible to change the PC-submitted JCL into two steps,
the first being an IEBGENR which would catalogue a file containing the ftp
commands for the mainframe's job... but that would create two difficulties
that I can see:
1) it would increase the minimal job listed above
2) unless the UID associated with running the job were given Prod access
then the control-card created would not be in the Standard Library of
SYS.PROD.CARDLIB... and we all know that Prod jobs must address *only*
Prod inputs and outputs. I could set up something like:
//JOBNAM01 JOB (P777,X888),'SITENAME - ORD DLOAD',CLASS=B,MSGCLASS=R,
// NOTIFY=XXXXXXX,MSGLEVEL=(1,1)
/*ROUTE PRINT R99
//STEP000 EXEC PGM=IEBGENER
//SYSUT1 DD *
100.100.100.101 <== IP address of PRIM
userid pwd <== logon ID for NT workstation
... <== other ftp cmds for establishing session & put
//SYSUT2 DD ATEMP.DSN,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(TRK,(1,1),RLSE),
// UNIT=SYSDA,
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=6400)
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD DUMMY
//*
//STEP001 EXEC UCC7SUB1
... but that would require, away down in tht ftp step:
//STEP110 EXEC PGM=FTP,COND=(0,NE),REGION=4096K,
// PARM='(EXIT'
//SYSOUT DD SYSOUT=*,DEST=LOCAL
//SYSPRINT DD SYSOUT=*,DEST=R99
//SYSIN DD DSN=ATEMP.DSN,DISP=(OLD,DELETE,DELETE)
... and this is forbidden, as ATEMP.DSN is *not* a member of
SYS.PROD.CARDLIB and, as it is written in the Book of Leviticus that Thou
Shalt Not Have Control-Card Input Other Than Those In SYS.PROD.CARDLIB.
Interesting idea, though, and one to hang on to for another time...
thanks!
DD
docd...@clark.net
Don Scott <sco...@nbnet.nb.ca> wrote:
>On 18 Mar 1999 14:37:00 GMT, docd...@clark.net () wrote:
>
>>
>>Any suggestions?
>>
>>DD
>
>The obvious, simple solution is to double-FTP the work-orders *every*
>time to both Primary and Backup.
Inelegant and 'expensive'... double-running jobs is *not* a way to endear
yourself to anyone in a strict-chargeback environment.
>
>The more exciting way to do it, of course, is to have the COBOL
>program dynamically create the SYSIN (or whatever) for the FTP process
>so that it ftp's to either xxx.xxx.xxx.ppp or xxx.xxx.xxx.bbb.
Impractical... the jobs run programs which already are doing similar
processing for a half-dozen other branches; when one does not need to
touch a program it is best that one does not do so.
>
>Going that way, you somehow have to signal to the COBOL program that
>it's either .ppp or .bbb at this moment in time. That can be done a
>number of ways, but maybe you can append something to the "request"
>file that identifies the requestor as the Primary or the Backup.
This is what we are trying to avoid, at the moment... the shop would
rather have two set of FRED to maintain than modify a program which is
already working for other branches; that is why I seek a solution using
JCL and procs.
>OR, maybe you can make it work *anywhere* by having the requestor
>machine submit its IP address along with the request, and then the
>COBOL program can dynamically create the ftp SYSIN (or whatever) to
>ftp the results to the requestor's IP, whether that be Primary, Backup
>or Joe's Machine in the Corner.
This was suggested by another and addressed there... the difficulty in
this one lies in increasing the complexity of 'offsite JCL', stored on the
originating machine (at present limited to a jobcard and a single EXEC) or
having a Prod job accept a non-Prod DSN as a SYSIN.
This is, however, a *very* good example as to why one must *always* be
cautious of *any* solution beginning with 'All ya gotta do is...' or a
semantic equivalent.
Thanks much!
DD
Don Scott
>In article <36f11c29...@news.nbnet.nb.ca>,
>Don Scott <sco...@nbnet.nb.ca> wrote:
>>On 18 Mar 1999 14:37:00 GMT, docd...@clark.net () wrote:
>>
>>>
>>>Any suggestions?
>>>
>>>DD
>>
>>The obvious, simple solution is to double-FTP the work-orders *every*
>>time to both Primary and Backup.
>
>Inelegant and 'expensive'... double-running jobs is *not* a way to endear
>yourself to anyone in a strict-chargeback environment.
>
I was actually suggesting FTP'ing the results file to two IP addresses
rather than one - not running the complete job twice - but if FTP cost
sensitivity is the issue, it must be one mother of a file.
DS
Donald Tees
regardless of who sends it; then it does not matter, the two are always in
synch ...
A station getting data back (when it did not send any) also knows from this
that it can scrap any pending input and start fresh.
Also the dual sending will handle primary sending, going down and secondary
needing to get data, or secondary sending, primary coming back up and
needing input, etc.
docd...@clark.net wrote in message <7cr32c$l2c$1...@callisto.clark.net>...
docd...@clark.net
Don Scott <sco...@nbnet.nb.ca> wrote:
>On 18 Mar 1999 15:50:56 GMT, docd...@clark.net () wrote:
>
>>In article <36f11c29...@news.nbnet.nb.ca>,
>>Don Scott <sco...@nbnet.nb.ca> wrote:
>>>On 18 Mar 1999 14:37:00 GMT, docd...@clark.net () wrote:
>>>
>>>>
>>>>Any suggestions?
>>>>
>>>>DD
>>>
>>>The obvious, simple solution is to double-FTP the work-orders *every*
>>>time to both Primary and Backup.
>>
>>Inelegant and 'expensive'... double-running jobs is *not* a way to endear
>>yourself to anyone in a strict-chargeback environment.
>>
>
>I was actually suggesting FTP'ing the results file to two IP addresses
>rather than one - not running the complete job twice - but if FTP cost
>sensitivity is the issue, it must be one mother of a file.
My apologies for not interpreting it in that manner.. no, the only problem
there is that the job would hang until timeout, the Backup and the Primary
are not powered-up simultaneously
DD
docd...@clark.net
>Actually, the elegant solution is to always send it back to both stations
>regardless of who sends it; then it does not matter, the two are always in
>synch ...
Not wuite... since the two machines are not running simultaneously (the
backup is kept turned off except for monthly tests nd actual use) the job
would time out and return an error
DD
SkippyPB
enlightened us:
>Actually, the elegant solution is to always send it back to both stations
>regardless of who sends it; then it does not matter, the two are always in
>synch ...
>
>A station getting data back (when it did not send any) also knows from this
>that it can scrap any pending input and start fresh.
>
>Also the dual sending will handle primary sending, going down and secondary
>needing to get data, or secondary sending, primary coming back up and
>needing input, etc.
>
The problem with sending it to two stations at the same time is that
the batch file to delete the previous-previous order file would only
get run on the station that initiates the download. Thus the files
would never be in sync on both stations.
Regards,
////
(o o)
-oOO--(_)--OOo-
Only Dead Fish Go With The Flow.
Steve
Thane Hubbell
> The latest installation I'm working on has *2* NT workstations, Primary
> and Backup. Under normal circumstances everything goes to Primary, of
> course... but when (*not* 'if', 'when') the Primary drops the Backup gets
> used. Everything about the processing initiated by either Primary or
> Backup is identical EXCEPT... except for the one line in the CARD member
> which directs the mainframe ftp back to the originating workstation. In
> other words, when Primary is used the first line of the CARD member will
> be, say, 100.100.100.101 (Primary's IP address) and when Backup is used
> this needs to be 100.100.100.102.
>
Will you detect the failure of the primary via the failure of the FTP?
Why not have TWO FTP steps - first to the primary, and if it is
successful, flush the next step.
You can detect success or failure of the FTP with this:
//STEPNUM EXEC PGM=FTP,PARM='100.100.100.1 (TIMEOUT 720 EXIT'
Then on your next EXEC put a COND=(0,GT)
Then the seocnd FTP won't go if the first one works.
docd...@clark.net
Ahhhh... this is starting to make sense. I wouldn't use the IP address as
part of the PARM because that is coming in through the CARD member but to
blow out the COND CODE...
... just tried it and I must be doing something wrong. Even though I can
read in the messages:
EZA1678I Foreign host rejected the open attempt (8547)
EZA1735I FTP Return Code = 10000
... and the JESout tells me:
IEF142I XXXXXXXY FTPSTP1 - STEP WAS EXECUTED - COND CODE 1808
... the second step still executes... and at the top of the JESlog I see:
13.29.03 JOB03137 XXXXXXXY 01 FTPSTP1 FTP ------------ 0000
13.29.04 JOB03137 XXXXXXXY 02 FTPSTP2 FTP ------------ 0000
... which is, of course, *utterly* absurd.
>
>Then on your next EXEC put a COND=(0,GT)
>
>Then the seocnd FTP won't go if the first one works.
It makes sense, aye... but for some reason the COND CODE of 1808 is being
suppressed to 0000. This seems to be the mechanism to use, though.
Thanks much... I'll keep experimenting and let you know how it goes.
DD
Howard Brazee
> successful, flush the next step.
>
> You can detect success or failure of the FTP with this:
>
> //STEPNUM EXEC PGM=FTP,PARM='100.100.100.1 (TIMEOUT 720 EXIT'
>
>
> Then the seocnd FTP won't go if the first one works.
I've done exactly that myself. But right now I have a slight change.
After subscribing to THE COBOL REPORT, I read the following article:
http://www.objectz.com/cobolreport/TCR_jcl.htm . It discusses two
relatively new features of JCL, the AVGREC parameter, and
IF-THEN-ELSE-ENDIF Condition code processing.
e.g.
// IF (STEP1.RC = 0 AND STEP2 <=6) THEN
//STEP3
...
// ELSE
//STEP4
...
// ENDIF
Donald Tees
docd...@clark.net wrote in message
>Not wuite... since the two machines are not running simultaneously (the
>backup is kept turned off except for monthly tests nd actual use) the job
>would time out and return an error
In that case, why different IP numbers?
Donald Tees
SkippyPB wrote in message ...
>>>The latest installation I'm working on has *2* NT workstations, Primary
>>>and Backup. Under normal circumstances everything goes to Primary, of
>>>course... but when (*not* 'if', 'when') the Primary drops the Backup gets
>>>used. Everything about the processing initiated by either Primary or
>>>Backup is identical EXCEPT... except for the one line in the CARD member
>>>which directs the mainframe ftp back to the originating workstation. In
>>>other words, when Primary is used the first line of the CARD member will
>>>be, say, 100.100.100.101 (Primary's IP address) and when Backup is used
>>>this needs to be 100.100.100.102.
>>>
docd...@clark.net
I'm sure there is a *very* good reason for this... but I write
applications and this is a hardware question.
DD
docd...@clark.net
Howard Brazee <bra...@NOSPAMhome.com> wrote:
>> Why not have TWO FTP steps - first to the primary, and if it is
>> successful, flush the next step.
>>
>> You can detect success or failure of the FTP with this:
>>
>> //STEPNUM EXEC PGM=FTP,PARM='100.100.100.1 (TIMEOUT 720 EXIT'
>>
>> Then on your next EXEC put a COND=(0,GT)
>>
>> Then the seocnd FTP won't go if the first one works.
>
>
>I've done exactly that myself. But right now I have a slight change.
Right now I have an even *worse* change. Thanks much, Mr Hubbel, but the
World is working strangely; while you suggest COND=(0,GT) I could not, as
stated in an earlier posting, get this to work... but
COND=(0,LT)
*does* work. Even though the JESlog shows:
14.38.27 JOB03893 XXXXXXXY 01 FTPSTP1 FTP ------------ 0000
14.38.40 JOB03893 XXXXXXXY 02 FTPSTP2 FTP ------------ NXEQ
...the invocations are:
//FTPSTP1 EXEC PGM=FTP,PARM='(EXIT'
... and ...
//FTPSTP2 EXEC PGM=FTP,COND=(0,LT),PARM='(EXIT'
This makes *absolutely* no sense to me whatsoever; I would conjecture that
since FTP can return a value greater than 4096 then there's some
high-order bit-twiddling going on which gets interpreted as a negative
number *even though it shows up as 0000*.
It makes no sense, as I said... but in the words of Captain COBOL:
IF JOBSTREAM-RUNS
PERFORM NEXT-ASSIGNMENT.
Thanks to all for the assistance, time and effort the applied to this bit
of a mess; my apologies for wasting your precious moments with so simple a
situation. Please do not construe this posting as a reason to stop
further research; would that I could apply more time in this manner!
DD
Roger Grady
In article <Jl0PnHJ5PvPd-pn2-CnWLR4jWp9dP@Dwight_Miller.iix.com>, red...@ibm.net (Thane Hubbell) writes:
>
> You can detect success or failure of the FTP with this:
>
> //STEPNUM EXEC PGM=FTP,PARM='100.100.100.1 (TIMEOUT 720 EXIT'
>
> Then on your next EXEC put a COND=(0,GT)
>
> Then the seocnd FTP won't go if the first one works.
Shouldn't that be COND=(0,GE)? Conditionals have always confused me -
they seem backwards - so I looked it up. (0,GT) bypasses the current
step only if 0 is greater than the return code from any previous step.
So unless the primary ftp issues a negative RC, the 2nd ftp step will
run.
Roger Grady K9OPO
spam block - remove ".qlf" for email address
HoeaJong
2. Invoke PROD.FRED.EAT.PROC
3. The car backfiring, with fred's belching will combine to form a
cacophony of such major proportions that everyone in the wharehouse will
believe someone's started a Q2 game without letting them know, and they kill
FTP and start Q2.
HTH
;)
Couldn't resist. sorry.
Steve Dover
>
> Will you detect the failure of the primary via the failure of the FTP?
>
> successful, flush the next step.
>
>
> //STEPNUM EXEC PGM=FTP,PARM='100.100.100.1 (TIMEOUT 720 EXIT'
>
> Then on your next EXEC put a COND=(0,GT)
>
He'll have to rework his logic on the NT side (file renames),
because the secondary will not be primed properly as originally
described. In addition, what happens when the FTP fails for
a transient condition even though the primary is still viable?
DD, have you considered a two-step approach? Not job based
on the mainframe, but user based on the NT side. The user
requests the file to be generated (almost all of what you
have already), but instead of the mainframe FTPing the file
to the NT via put, have the user request the file via FTP get.
After the user can somehow determine that the file was
successfully generated.
This way, the user requests the generation of the file which
can be done from any NT box, and can get the file to any NT box.
Let me guess. That's too complicated for the users.
--
Are you ready for year MM?
The Mother of all Messes.
288 Days to go before 'Ignorance is bliss' is obsolete.
news:comp.software.year-2000 Come for the signal, stay for the noise.
Donald Tees
>I'm sure there is a *very* good reason for this... but I write
>applications and this is a hardware question.
Aye, I forget sometimes that people do only parts of things. As a VAR, we
often have an advantage. I set everything up here in the office, all
computers, all printers, all devices, then disassemble and ship it out. The
only thing different in the field is the length of the cables can be up to
12,000 miles. If some local weanie changes an IP number, I charge from the
time I put my coat on to the time I arrive home. We often have upstream
networks, but everything from my server on down is *MINE*!.
Donald Tees
NT desktop. The user opens the head office folder, and drops in the
transaction file. Then when they need new orders, they open the head office
folder on the machine they happen to be running, drag the new orders over to
the system, then drop them in. That is the way I transfer data tickets from
my dispatch systems to head office and get price data back.
Steve Dover wrote in message <36F17E2C...@strata-group.Xcom>...
Thane Hubbell
>In article <Jl0PnHJ5PvPd-pn2-CnWLR4jWp9dP@Dwight_Miller.iix.com>,
>Thane Hubbell <red...@ibm.net> wrote:
>>On Thu, 18 Mar 1999 14:37:00, docd...@clark.net () wrote:
>>
>>> The latest installation I'm working on has *2* NT workstations, Primary
>>> and Backup. Under normal circumstances everything goes to Primary, of
>>> course... but when (*not* 'if', 'when') the Primary drops the Backup gets
>>> used. Everything about the processing initiated by either Primary or
>>> Backup is identical EXCEPT... except for the one line in the CARD member
>>> which directs the mainframe ftp back to the originating workstation. In
>>> other words, when Primary is used the first line of the CARD member will
>>> be, say, 100.100.100.101 (Primary's IP address) and when Backup is used
>>> this needs to be 100.100.100.102.
>>>
>>
>>Will you detect the failure of the primary via the failure of the FTP?
>>
>>Why not have TWO FTP steps - first to the primary, and if it is
>>successful, flush the next step.
>>
>>You can detect success or failure of the FTP with this:
>>
>>//STEPNUM EXEC PGM=FTP,PARM='100.100.100.1 (TIMEOUT 720 EXIT'
>
>Ahhhh... this is starting to make sense. I wouldn't use the IP address as
>part of the PARM because that is coming in through the CARD member but to
>blow out the COND CODE...
>
I think you MUST use it on the EXEC in order to make it work. You
should be able to use PARM="(EXIT"
then use the IP address in the card menber.
(The 5 minute timeout I have is excessive - except what I use it for
is a dial up router - so I need to wait for the phone line connection
etc).
Thane Hubbell
Grady) wrote:
>
>In article <Jl0PnHJ5PvPd-pn2-CnWLR4jWp9dP@Dwight_Miller.iix.com>, red...@ibm.net (Thane Hubbell) writes:
>
>>
>> You can detect success or failure of the FTP with this:
>>
>> //STEPNUM EXEC PGM=FTP,PARM='100.100.100.1 (TIMEOUT 720 EXIT'
>>
>> Then on your next EXEC put a COND=(0,GT)
>>
>> Then the seocnd FTP won't go if the first one works.
>
>Shouldn't that be COND=(0,GE)? Conditionals have always confused me -
>they seem backwards - so I looked it up. (0,GT) bypasses the current
>step only if 0 is greater than the return code from any previous step.
>So unless the primary ftp issues a negative RC, the 2nd ftp step will
>run.
I think Howard is on the right track. You are correct! Hey DOC! My
GT is WRONG. But GE won't work either - because if the first step
worked then the code would be 0, how about COND=(1,GE) - hows that
work DD?
docd...@clark.net
Steve Dover <s...@strata-group.Xcom> wrote:
>Thane Hubbell wrote:
>>
>> Will you detect the failure of the primary via the failure of the FTP?
[snippage]
>He'll have to rework his logic on the NT side (file renames),
>because the secondary will not be primed properly as originally
>described. In addition, what happens when the FTP fails for
>a transient condition even though the primary is still viable?
>
[snippolinio]
>This way, the user requests the generation of the file which
>can be done from any NT box, and can get the file to any NT box.
>
>Let me guess. That's too complicated for the users.
In a nut-shell... yep. The file-renames and suchlike are really icings on
the cake; they were not requested (I can't say that they didn't appear in
the spec because... no specs!) but I put 'em in for free... a coder's
gotta do what a coder's gotta do. Asking the user to do two requests and
file verifications is going to be considered to be A Bit Much.
Thanques for the thought, though!
DD
docd...@clark.net
Donald Tees <don...@willmack.com> wrote:
>If you are going to do it that way, you just have some file folders on the
>NT desktop. The user opens the head office folder, and drops in the
>transaction file.
Nice thinking... but, as I mentioned to Mr Dover, any approach demanding
that sort of sophistication is deemed 'too complex for the user'; what is
wanted (and what, at present, exists in the other, non-backed-up
installations), is an icon they click, a 1-minute wait and then they open
up their NT software, click on the 'Import Orders' function (already
defaulting to the incoming ftp directory and filename) and there they go.
Yes, I agree that the kind of approach you suggest is possible BUT... the
folks who sing my timesheet want the kind of nigh-idiotproffing I've
delivered on the other sites.
Thanks much for your time and effort, though!
DD
docd...@clark.net
HoeaJong <ca...@enteract.com> wrote:
[snippage of references to tropical fruits and exhaust-gasses]
>Couldn't resist. sorry.
Not to worry, old boy... I've eaten a lot of sausages in my time, so...
... I've lived through much wurst than that.
DD
cory hamasaki
hoff_meister
Actually, I thought your original process was the best. It is more
"generalized", in that the process can be duplicated for more than one
application. I know, your situation is a single app, but these things
have a tendency to multiply.
One more thought. Someone else mentioned a two-step process, where the
NT user requests the FTP back. Your objection was that it was too
"complicated" for the user, something I understand completely. But it
seems you already have a two-step process, in that the user must start
up the "import". Is there a batch interface to the software on the NT,
where you could setup a command file to do both the FTP back, and the
import?
Finally, probably a dumb question, as my mainframe experience is quite
hazy. But doesn't the UID your using require PROD access to write to
the internal reader?
Hoffmeister
docd...@clark.net
docd...@clark.net
Understood and granted, almost reflexively... that's why I've learned to
write code the way I do; the number of times that things which were to
have been done 'just this once' have been worked into the Prod jobstream
is large.
>
>One more thought. Someone else mentioned a two-step process, where the
>NT user requests the FTP back. Your objection was that it was too
>"complicated" for the user, something I understand completely. But it
>seems you already have a two-step process, in that the user must start
>up the "import". Is there a batch interface to the software on the NT,
>where you could setup a command file to do both the FTP back, and the
>import?
I'm not sure I understand what is meant here... the user, by clicking the
icon, starts off the whole rigamarole which ends (no evil eye!) with a
new, fresh file on the NT; this file is then imported into the user's
application. The user does *not*, necessarily, want a new download every
time the application is started; what I read you as asking would lead to
such a thing, no?
>
>Finally, probably a dumb question, as my mainframe experience is quite
>hazy. But doesn't the UID your using require PROD access to write to
>the internal reader?
Doesn't seem to be that way, nope!
DD
John Galt
docd...@clark.net wrote in message <7csgq9$2gm$1...@callisto.clark.net>...
<snip>
>
>Yes, I agree that the kind of approach you suggest is possible BUT... the
DD: you statement clearly implies that you have your timesheets delivered in
singing telegrams, and that more than one person is involved in the
delivery... a choir perhaps?
-JG
hoff_meister
>
<snip>
>
> I'm not sure I understand what is meant here... the user, by clicking the
> icon, starts off the whole rigamarole which ends (no evil eye!) with a
> new, fresh file on the NT; this file is then imported into the user's
> application. The user does *not*, necessarily, want a new download every
> time the application is started; what I read you as asking would lead to
> such a thing, no?
>
No. Most (some?) of the time, the software app on the NT will have
command line options to perform specific tasks, like the import. You
described a 2 step process for the user; initiate the request, which
ends with a file on the NT, then starting the app, and initiating the
import. IF the software allows command line options to specifically
perform the import, step 2 could be a command file which would FTP the
data from the mainframe, then initiate the app to do the import.
Kind of related, my current client uses essentially the same mechanism
for outbound EDI processing. They use GENTRAN on the mainframe to map
from SAP IDOC's to the EDI format, and following the FTP from the SAP
system to the mainframe, they write to the internal reader to initiate
the GENTRAN process. Admittedly, it doesn't have to resend data *back*,
as in your case. But we're modifying the process to use a *trigger*
dataset, utilizing CA7 software on the mainframe to initiate the
processing based on the creation of the trigger dataset, instead of
writing to the internal reader.
Hoffmeister
docd...@clark.net
(now watch closely... the twisted syntax allows for the punch-line to come
at the end)
Of *course* it is a chorus... how else do you think that I, in prompt
manner, my fully-signed timesheets a-choired?
DD
Dave Eastabrook
>
>docd...@clark.net wrote in message <7csgq9$2gm$1...@callisto.clark.net>...
><snip>
>>
>>Yes, I agree that the kind of approach you suggest is possible BUT... the
>>folks who sing my timesheet ...
>
>DD: you statement clearly implies that you have your timesheets delivered in
>singing telegrams, and that more than one person is involved in the
>delivery... a choir perhaps?
As long as the choir doesn't get reamed out by the boss, then I suppose
it doesn't matter a lot!
:Dave
cory hamasaki
docd...@clark.net
hoff_meister <hoff_m...@my-dejanews.com> wrote:
>docd...@clark.net wrote:
>>
><snip>
>>
>> I'm not sure I understand what is meant here... the user, by clicking the
>> icon, starts off the whole rigamarole which ends (no evil eye!) with a
>> new, fresh file on the NT; this file is then imported into the user's
>> application. The user does *not*, necessarily, want a new download every
>> time the application is started; what I read you as asking would lead to
>> such a thing, no?
>>
>
>No. Most (some?) of the time, the software app on the NT will have
>command line options to perform specific tasks, like the import. You
>described a 2 step process for the user; initiate the request, which
>ends with a file on the NT, then starting the app, and initiating the
>import. IF the software allows command line options to specifically
>perform the import, step 2 could be a command file which would FTP the
>data from the mainframe, then initiate the app to do the import.
Ahhhh, I think I see... as mentioned above, the user can invoke the
application without wanting to initiate a new download; likewise, the user
can invoke the app in order to work with previously imported data and
*not* want to perform a fresh import, hence no automatic import for step
2. Am I somewhat clearer?
[snippage]
>But we're modifying the process to use a *trigger*
>dataset, utilizing CA7 software on the mainframe to initiate the
>processing based on the creation of the trigger dataset, instead of
>writing to the internal reader.
How curious... any idea what kind of overhead is involved in said
trigger-monitoring? I wonder why this kind of sentinel-setting is
considered to be A Better Thing than using the INTRDR... but I'm sure
there's a Very Good Reason for having the system burn up resources
watching for a trigger-event rather than only on demand.
DD
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
hoff_meister
>
> In article <36F25B...@my-dejanews.com>,
> hoff_meister <hoff_m...@my-dejanews.com> wrote:
> >docd...@clark.net wrote:
> >>
> ><snip>
> >>
> >> I'm not sure I understand what is meant here... the user, by clicking the
> >> icon, starts off the whole rigamarole which ends (no evil eye!) with a
> >> new, fresh file on the NT; this file is then imported into the user's
> >> application. The user does *not*, necessarily, want a new download every
> >> time the application is started; what I read you as asking would lead to
> >> such a thing, no?
> >>
> >
> >No. Most (some?) of the time, the software app on the NT will have
> >command line options to perform specific tasks, like the import. You
> >described a 2 step process for the user; initiate the request, which
> >ends with a file on the NT, then starting the app, and initiating the
> >import. IF the software allows command line options to specifically
> >perform the import, step 2 could be a command file which would FTP the
> >data from the mainframe, then initiate the app to do the import.
>
> Ahhhh, I think I see... as mentioned above, the user can invoke the
> application without wanting to initiate a new download; likewise, the user
> can invoke the app in order to work with previously imported data and
> *not* want to perform a fresh import, hence no automatic import for step
> 2. Am I somewhat clearer?
>
Yes. What I was suggesting was basically a separate "icon", if you
will, to perform the FTP/import step.
> [snippage]
> >But we're modifying the process to use a *trigger*
> >dataset, utilizing CA7 software on the mainframe to initiate the
> >processing based on the creation of the trigger dataset, instead of
> >writing to the internal reader.
>
> How curious... any idea what kind of overhead is involved in said
> trigger-monitoring? I wonder why this kind of sentinel-setting is
> considered to be A Better Thing than using the INTRDR... but I'm sure
> there's a Very Good Reason for having the system burn up resources
> watching for a trigger-event rather than only on demand.
>
> DD
Don't know about the overhead. The basic reasoning is that *bad things*
can happen if (when) something screws up with the write to the internal
reader. In addition, at this location, the powers that be have decreed
that thou shalt not write to the internal reader on the *test* system,
only in *production*. Which makes testing the process, err, somewhat
complex.
Hoffmeister
docd...@clark.net
[snippage]
>> Ahhhh, I think I see... as mentioned above, the user can invoke the
>> application without wanting to initiate a new download; likewise, the user
>> can invoke the app in order to work with previously imported data and
>> *not* want to perform a fresh import, hence no automatic import for step
>> 2. Am I somewhat clearer?
>>
>
>Yes. What I was suggesting was basically a separate "icon", if you
>will, to perform the FTP/import step.
Yes, *much* clearer... the download of the file from the mainframe to the
NT box is completely separate from the importing of the downloaded data
into the NT's application. Funny you should mention it, though... after
all this brou-ha-ha it turns out that Due To Stuff I Wasn't Told Before I
may have to go to this 2-icon (one to kick off the job, the other to ftp
the data down) *anyhow*... but I should 'build in' steps which allow for a
switchover to 1-icon initiation by year-end.
But hey... if it were easy then *everyone* would be doing it, neh?
[snippage]
>> How curious... any idea what kind of overhead is involved in said
>> trigger-monitoring? I wonder why this kind of sentinel-setting is
>> considered to be A Better Thing than using the INTRDR... but I'm sure
>> there's a Very Good Reason for having the system burn up resources
>> watching for a trigger-event rather than only on demand.
>
>Don't know about the overhead.
Ah HA, by their admissions ye shall know them... it is obvious that you
are not Management, as Management would have responded 'That's a *good*
question... '
>The basic reasoning is that *bad things*
>can happen if (when) something screws up with the write to the internal
>reader. In addition, at this location, the powers that be have decreed
>that thou shalt not write to the internal reader on the *test* system,
>only in *production*. Which makes testing the process, err, somewhat
>complex.
How nice... don't tell me, what comes next is elimination of the database
on the test system so that everything has to be done with indexed files,
instead?
DD
Alan Maitland
docd...@clark.net wrote in message <7crct1$e1$1...@clarknet.clark.net>...
--snip--
>>I was actually suggesting FTP'ing the results file to two IP addresses
>>rather than one - not running the complete job twice - but if FTP cost
>>sensitivity is the issue, it must be one mother of a file.
>
>My apologies for not interpreting it in that manner.. no, the only problem
>there is that the job would hang until timeout, the Backup and the Primary
>are not powered-up simultaneously
>
>DD
>
Given Mr. Hamaskaki's post, it would seem that the largest problem is one at
the FTP level from the mainframe back to the NT boxes.
Is there a utility on the mainframe that can PING an IP address and set up a
JCL variable that would ack or nak the ping?
Based on the result of the ping variable, the JCL could decide if it wants
to transfer the file via FTP or not.
Given this type of utility, Don Scott's solution should work fine for the
dual FTP submission process to the primary and secondary NT boxes.
I would be amazed if such a utility did not exist as it should be very easy
to create. Of course, I have been amazed by less.
Hope this helps.
Best,
Alan Maitland
President
NBCI.Net
Pay attention - stay alive
hoff_meister
>
> In article <36F269...@my-dejanews.com>,
> hoff_meister <hoff_m...@my-dejanews.com> wrote:
> >docd...@clark.net wrote:
>
> [snippage]
>
> >> Ahhhh, I think I see... as mentioned above, the user can invoke the
> >> application without wanting to initiate a new download; likewise, the user
> >> can invoke the app in order to work with previously imported data and
> >> *not* want to perform a fresh import, hence no automatic import for step
> >> 2. Am I somewhat clearer?
> >>
> >
> >Yes. What I was suggesting was basically a separate "icon", if you
> >will, to perform the FTP/import step.
>
> Yes, *much* clearer... the download of the file from the mainframe to the
> NT box is completely separate from the importing of the downloaded data
> into the NT's application.
But they *may* be combined into a two-step command file, again assuming
a batch interface in the software.
> Funny you should mention it, though... after
> all this brou-ha-ha it turns out that Due To Stuff I Wasn't Told Before I
> may have to go to this 2-icon (one to kick off the job, the other to ftp
> the data down) *anyhow*... but I should 'build in' steps which allow for a
> switchover to 1-icon initiation by year-end.
>
> But hey... if it were easy then *everyone* would be doing it, neh?
>
> [snippage]
>
> >> How curious... any idea what kind of overhead is involved in said
> >> trigger-monitoring? I wonder why this kind of sentinel-setting is
> >> considered to be A Better Thing than using the INTRDR... but I'm sure
> >> there's a Very Good Reason for having the system burn up resources
> >> watching for a trigger-event rather than only on demand.
> >
> >Don't know about the overhead.
>
> Ah HA, by their admissions ye shall know them... it is obvious that you
> are not Management, as Management would have responded 'That's a *good*
> question... '
>
Yes, well there are *different* levels of Management, mine being
"Project" related. "They" control the actual operations.
> >The basic reasoning is that *bad things*
> >can happen if (when) something screws up with the write to the internal
> >reader. In addition, at this location, the powers that be have decreed
> >that thou shalt not write to the internal reader on the *test* system,
> >only in *production*. Which makes testing the process, err, somewhat
> >complex.
>
> How nice... don't tell me, what comes next is elimination of the database
> on the test system so that everything has to be done with indexed files,
> instead?
>
> DD
Not *quite* that bad, but it was this situation which led to my earlier
question regarding PROD access to write to the internal reader.
Hoffmeister
docd...@clark.net
Alan Maitland <AMai...@NBCI.Net> wrote:
>DD,
>
>docd...@clark.net wrote in message <7crct1$e1$1...@clarknet.clark.net>...
>--snip--
>>>I was actually suggesting FTP'ing the results file to two IP addresses
>>>rather than one - not running the complete job twice - but if FTP cost
>>>sensitivity is the issue, it must be one mother of a file.
>>
>>My apologies for not interpreting it in that manner.. no, the only problem
>>there is that the job would hang until timeout, the Backup and the Primary
>>are not powered-up simultaneously
>>
>>DD
>>
>
>Given Mr. Hamaskaki's post, it would seem that the largest problem is one at
>the FTP level from the mainframe back to the NT boxes.
>
>Is there a utility on the mainframe that can PING an IP address and set up a
>JCL variable that would ack or nak the ping?
Hmmmm... there is a PING program, similar to the FTP; diddling about with
it (doc?... who has doc?) shows that unless I find out how to send
multiple PINGs (a PARM someplace?) it only sends one... and I wouldn't
want to direct my processing based on a single failed PING.
>
>Based on the result of the ping variable, the JCL could decide if it wants
>to transfer the file via FTP or not.
True... PING gives a RETURN CODE (COND CODE) of 0000 for a success but,
once again, I need more than one transmission.
>
>Given this type of utility, Don Scott's solution should work fine for the
>dual FTP submission process to the primary and secondary NT boxes.
A slight variation is being implemented, as suggested by Mr Hubbel; an FTP
will be attempted to the Primary and only if that fails will one be made
for the Backup.
DD
docd...@clark.net
hoff_meister <hoff_m...@my-dejanews.com> wrote:
>docd...@clark.net wrote:
>>
>> In article <36F269...@my-dejanews.com>,
>> hoff_meister <hoff_m...@my-dejanews.com> wrote:
>> >docd...@clark.net wrote:
>>
>> [snippage]
>>
[snippage]
>> Yes, *much* clearer... the download of the file from the mainframe to the
>> NT box is completely separate from the importing of the downloaded data
>> into the NT's application.
>
>But they *may* be combined into a two-step command file, again assuming
>a batch interface in the software.
Nearly anything *may* be something else... what I know is that they *are*
not now and the need is to program for this. Next week... who knows?
DD
Jacques Bernier
I am so glad you have found a real life problem that cause you to post
and discuss to you heart's content these weighty matters. No fool's
gold here.
*Many* of us read them in awe and actually understand your sentences
even if, alas, we don't have a clue about their meaning
By the way, I am patenting an invention of mine that could, if used
wisely, enhanced considerably your already prodigious semantic power.
I am proudly announcing the " Gold foil and egg salad hat". It will be
backward compatible with the Olde Tin interface and retain all
previous properties. That is a real programming feat, nay?
Rejoice,
JB
On 19 Mar 1999 18:01:13 GMT, docd...@clark.net () wrote:
snip
>Hmmmm... there is a PING program, similar to the FTP; diddling about with
>it (doc?... who has doc?) shows that unless I find out how to send
>multiple PINGs (a PARM someplace?) it only sends one... and I wouldn't
>want to direct my processing based on a single failed PING.
snip
docd...@clark.net
Jacques Bernier <jber...@microtec.net> wrote:
>Ah! Mr. Dwarf, what a lovely prose. Ack, nak, ping, parm,doc.
Almost *sings*, doesn't it?
>
>I am so glad you have found a real life problem that cause you to post
>and discuss to you heart's content these weighty matters. No fool's
>gold here.
M Bernier, I am confused... if, as indicated below, you are a part of the
'we' which does not 'have a clue about their meaning' then how can you
conclude if I am spewing pyrite or not?
>
>*Many* of us read them in awe and actually understand your sentences
>even if, alas, we don't have a clue about their meaning
Plural majestatus est.
>
>By the way, I am patenting an invention of mine that could, if used
>wisely, enhanced considerably your already prodigious semantic power.
>
>I am proudly announcing the " Gold foil and egg salad hat". It will be
>backward compatible with the Olde Tin interface and retain all
>previous properties. That is a real programming feat, nay?
As does *any* 'real programmer', M Bernier, I wear boots - in my case they
are (usually) well-polished boots of the kind issued to me when I enlisted
in the Air Force Reserves, lo, those many decades ago - while coding; I
find that these quite nicely permit my hands to work and prevent folks
from dealing with the rampant confusions which might be cause by my...
... programming feet.
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
Ken Foskey
I have been reading your FTP thread with interest.
First I have used FTP for large transfers to multiple systems. It is
solid and rarely fails. Phooey to the person that says otherwise.
Thou shalt not use magic numbers: Give the IP addresses and name and
sit them in the MVS table, if the main machine breaks get the hosts
table updated with the new number. This wont work if it has to happen
instantly or you do not have a friendly sysprog.
If you do not want to go through a ftp failure first: Get the parameter
from the PC's, set up the two FTP steps and install a minute cobol
program that inspects the parameter and issues a Condition code 0 for
primary, 1 for secondary, etc.
The problem is that you must be able to call UCC7 with PARM=??? and get
it through the submission process. This is fairly normal for these
types of tools, any experts?
PC solution: Write a program that logs onto the MVS box and does a
directory listing (ls). Loop until file has been found. call ftp on
the PC and download the file. This solution can give a waiting signal
to the user. Since you are already FTPing from the PC I would assume
most of the problems with this are worked out.
Jeff
patience would allow.
Here is my 2 bits.
First FTP'ing directly to the internal reader is a very dangerous thing. It
bypasses security protocols which most mainframers are forced to submit to.
From your explanation it sounds like you are one of those PC/Mainframe
Stealth programmers who bypass production control by FTP'ing directly to the
internal reader. Not that I am putting you down, but that is a very
dangerous thing to do. It is a major violation of security, especially if
your FTP connection is open to the Internet.
Along that line, can you send me an example of how this is done? I am trying
to write a program which can freely transmit itself from PC to Mainframe and
then back in order to cross the PC/Mainframe species barrier......
What I would do, as a mainframe programmer, would be to modify an existing
job, or create and schedule a new job to create your extract file on a
regular basis in such a way as to keep the extract file current with
production data. Then all you would have to do is download the data directly
to your PC.
If you are using something like MS ACCESS you can have a direct ftp link to
the file, at least under NT. If you are using DB2 on the mainframe ACCESS
can directly link to the DB through FTP using what I believe is a DB2 ODBC
driver. Sorry, can't help you on the details with this one. I've just seen
it done, wasn't able to get security on my PC. After all it would be far too
easy if I could see the data I was working with.
That's just my opinion, I could be wrong.
Don Scott
>(Note: a couple of contracts back I just *happened* to have done something
>like this.. the PHM originally wanted a standalone program to load the DB2
>table via INSERTs despite my suggesting that it would be superior to use
>IKJEFT01. I put together the code and jobstreams to do as he requested
>and then used the time during the test runs to Do The Job Right. We
>finally did it using IKJEFT01 because the INSERT program would be
>cancelled by Ops after 36 hours' running... it *never* completed.
>IKJEFT01 would load about 35M rows into two databases after a 'mere' 9
>hours.)
>
>DD
Just a question on techniques here:
Are you running the same program in both cases - first as a standalone
under its own EXEC, and then under IKJEFT01 as a sub-task?
Or are you instead invoking a totally different LOAD (INSERT) command
under IKJEFT01?
DS
The Goobers
My apologies for the lack of clarity, Mr Scott; the latter is the case,
where the COBOL was invoked in one jobstream via EXEC PGM=PROGNAME and
the IKJEFT01 invoked the LOAD command.
DD
The Goobers
>
> Gday Doc,
>
> I have been reading your FTP thread with interest.
Good day, Mr Foskey! Thanks much for e'er-so-indulgently putting up
with my laziness.
>
> First I have used FTP for large transfers to multiple systems. It is
> solid and rarely fails. Phooey to the person that says otherwise.
Agreed; the guts of the file transfer protocol have been rather solid
for a couple of decades now.
>
> Thou shalt not use magic numbers: Give the IP addresses and name and
> sit them in the MVS table, if the main machine breaks get the hosts
> table updated with the new number. This wont work if it has to happen
> instantly or you do not have a friendly sysprog.
Then, sadly... it will not work. The Primary and Backup machines will
be among users of... minimal technical sophistication; the expectation
is that when the Primary dies someone will (or 'should be able to') shut
it down, fire up the Backup and carry on with their usual tasks without
bothering (read 'notifying') anyone. Add to this the fact that the site
with the PC's is approximately 1,500 miles from the mainframe site and
the odds of running into a 'friendly sysprog' decreases with distance...
and one has, as the Germans say, 'plein du merde'.
>
> If you do not want to go through a ftp failure first: Get the parameter
> from the PC's, set up the two FTP steps and install a minute cobol
> program that inspects the parameter and issues a Condition code 0 for
> primary, 1 for secondary, etc.
Not an impossible mechanism... but, I would argue, an undesireable one;
one o the restrictions of this situation is that we are trying to use
the same jobstreams for both the one-machine sites we already have and
the two-machine site which I am dealing with.
>
> The problem is that you must be able to call UCC7 with PARM=??? and get
> it through the submission process. This is fairly normal for these
> types of tools, any experts?
No expert needed, Mr Foskey, I am proficient enough to do this myself...
again, not impossible but it would require, as you've noted, an
additional program or step in the FRED proc to determine the origin
(Primary or Backup, in the absence of either then an 'Only' assumed).
The success of an ftp step to a 'primary' (either a true Primary or the
'Only') will create a COND which can be checked to either initiate or
skip the second ftp.
>
> PC solution: Write a program that logs onto the MVS box and does a
> directory listing (ls). Loop until file has been found. call ftp on
> the PC and download the file. This solution can give a waiting signal
> to the user. Since you are already FTPing from the PC I would assume
> most of the problems with this are worked out.
Ow ow ow... it can be made to work, true, but the attempt is being made
to keep as much *off* the PC as possible; that is why I've limited
myself to the most basic of batch files and three lines of JCL. The
last thing the Home Office wants is a change in procedures which
requires trying to talk a warehouseman through reconfiguring a PC in a
dispactching-office 3,000 miles away.
Thanks much for your time, though... come the latter part of next week
I'll be back on-site at the warehouse, testing these things and letting
folks know how it all worked.
DD
The Goobers
>
> First off, I tried to read as many of the replies to your request as my
> patience would allow.
>
> Here is my 2 bits.
>
> First FTP'ing directly to the internal reader is a very dangerous thing.
I agree wholeheartedly.
> It
> bypasses security protocols which most mainframers are forced to submit to.
I agree with this as well; that is why what I ftp to the INTRDR is
nothing more than an EXEC of a proc which invokes UCC7 with the *real*
job so that security protocols can be adhered-to.
> From your explanation it sounds like you are one of those PC/Mainframe
> Stealth programmers who bypass production control by FTP'ing directly to the
> internal reader.
I can understand how you have come to this conclusion... but it is an
incorrect one; had your patience allowed you to read more replies you
might have seen my showing a demand for 'one solution for all; change
the parms, not the jobs' which indicates a more of a mainframe
background.
> Not that I am putting you down, but that is a very
> dangerous thing to do. It is a major violation of security, especially if
> your FTP connection is open to the Internet.
I agree.
>
> Along that line, can you send me an example of how this is done? I am trying
> to write a program which can freely transmit itself from PC to Mainframe and
> then back in order to cross the PC/Mainframe species barrier......
... and violate the security in the manner of a PC/Mainframe Stealth
Programmer? How droll!
>
> What I would do, as a mainframe programmer, would be to modify an existing
> job, or create and schedule a new job to create your extract file on a
> regular basis in such a way as to keep the extract file current with
> production data. Then all you would have to do is download the data directly
> to your PC.
Once you have access to the INTRDR you can submit any series of jobcards
that you want, of course; that is the power and the danger of the whole
mechanism. Imagine, if you would, sending in a typical COBUCLG stream
for an instream compile and execution... no, even *better*, an
invocation of IFOX00... whoops, sorry, that's obsolete, I meant IEV90, I
think.
>
> If you are using something like MS ACCESS you can have a direct ftp link to
> the file, at least under NT.
The direct ftp link I use is invoked from the NT at the command prompt
(to send to the mainframe); this SUBmits the initial JCL (jobcard and
EXEC statement only) which fires off the proc which invokes UCC7. After
this initial SUBmit the ftp connection to the mainframe is closed; when
mainframe processing is completed (approx 30 sec later) a connection is
established, mainframe-to-micro, to ftp the data back down.
In order to establish the second connection the NT needs to be running
ftp-server software of some kind... if it is not then the
mainframe-to-micro file transfer can still be accomplished BUT it is
done with a micro-to-mainframe get rather than a mainframe-to-micro put.
> If you are using DB2 on the mainframe ACCESS
> can directly link to the DB through FTP using what I believe is a DB2 ODBC
> driver. Sorry, can't help you on the details with this one. I've just seen
> it done, wasn't able to get security on my PC. After all it would be far too
> easy if I could see the data I was working with.
Sounds like you don't need 'security', per se, but just the file... am I
correct in concluding this?
>
> That's just my opinion, I could be wrong.
Hence my asking, of course.
DD
Ron Schwarz -- see sig to reply
>
>Alright, gang.. I've got a moderately juicy one upon which I would
>appreciate a modicum of assistance.
>
>What I've been doing lately is only tangentially COBOL-related... but it
>beats the heck outta Y2K remediation for holding my interest! The company
>I've contracted with has Stuff 'n Processing on the mainframe and Stuff 'n
>Processing on the PC (actually networked NTs) and data need to be bounced
>from one to the other. I've set up a series of four mechanisms which
>kinda sorta maybe boil down to these steps:
>
>The geepo in the warehouse figures 'Hey, time to download the latest set
>of orders that were entered on the mainframe!'... and double-clicks on an
>icon I've set up for this purpose.
>
>The icon invokes a batch file.
>
>The batch file deletes the previous-previous order file, renames the
>previous order file 'OldOrd' (or something like that) and invokes ftp
>using the -s option and the mainframe's IP address as the target.
>
>The file specified by the -s option logs onto the mainframe and submits a
>job to the internal reader.
>
>The job submitted to the internal reader executes a proc (one of those
>plain ol' proc-type procs, in SYS.PROD.PROCLIB)
>
>The executed proc consists of two steps: an IEFBR14 (don't ask me why but
>the guys in Ops said this 'dummy step' was necessary) and an invocation of
>UCC7 (PGM=U7SVC)... and the PARM of this invocation specifies some JCL
>which UCC7 is supposed to submit.
>
>(note: this is done so a record of the JCL's run will be kept by UCC7)
>
>The JCL submitted by the invocation of UCC7 by the proc executed by the
>JCL submitted to the internal reader by the ftp invoked by the batch file
>executed by the operator's clicking on the NT icon (still with me so far?)
>invokes another proc which does the actual work... for the sake of clarity
>I'll call this proc FRED.
>
>FRED, at heart, consists of two steps... a COBOL job (which I wrote... see
>where the 'lang.cobol' fits in?) and another ftp. The COBOL job runs
>against the mainframe databases (DataComm), extracts the orders that the
>warehouse-gang needs and dumps these to a flat-file. The flat-file is
>then ftp'd by the next step back down to the PC so the warehouse crew can
>take care of their own jobs.
>
>Now that I've explained all that I can get to the guts of my request. The
>ftp step in the proc FRED uses a standard sort of SYSIN member from
>SYS.PROD.CARDLIB. This member directs the ftp to the target system... in
>this case, the IP address of the NT workstation which originated the
>request.
>
>The latest installation I'm working on has *2* NT workstations, Primary
>and Backup. Under normal circumstances everything goes to Primary, of
>course... but when (*not* 'if', 'when') the Primary drops the Backup gets
>used. Everything about the processing initiated by either Primary or
>Backup is identical EXCEPT... except for the one line in the CARD member
>which directs the mainframe ftp back to the originating workstation. In
>other words, when Primary is used the first line of the CARD member will
>be, say, 100.100.100.101 (Primary's IP address) and when Backup is used
>this needs to be 100.100.100.102.
>
>I'm looking for as elegant a way to deal with this as possible. The most
>ready solution would be to have two versions of FRED, FREDPRIM and
>FREDBACK, and the only difference between the two would be in the SYSIN
>for the ftp step.. FREDA would pull in SYS.PROD.CARDLIB(FTPPRIM), FREDB
>would pull in SYS.PROD.CARDLIB(FTPBACK) and the only difference in these
>CARD members would be the IP address mentioned above.
>
>The more elegant solution would be to be able to supply, via override,
>either the DD for the ftp step in FRED or the suffix of the member-name
>via symbolic... but I'm not sure if such a thing can be preserved through
>the layer upon layer of JCL and proc and UCC7 and JCL and proc that I've
>described.
>
>Any suggestions?
Fools jumping in where angels fear to tread and all that, I'd suggest the most
elegant solution would be ODBC (or ADO, etc) as suggested by another poster.
Failing that (no VB compiler and mainframe data access toolkits available), I'd
suggest that they do what they should have been doing anyway -- use local DNS.
Instead of pointing FTP at an IP address, aim it at a *name*. If they take one
machine out of service, have them update the DNS to resolve the *other* machine.
Give the entry a very short TTL.
--
When they say, "Eat your spam," I say, "Drink your [purple] Koolaid".
Sender: crosscut
Domain: killtrees.com
The Goobers
[snippage]
> Failing that (no VB compiler and mainframe data access toolkits available), I'd
> suggest that they do what they should have been doing anyway -- use local DNS.
> Instead of pointing FTP at an IP address, aim it at a *name*. If they take one
> machine out of service, have them update the DNS to resolve the *other* machine.
> Give the entry a very short TTL.
Greatly appreciated, Mr Schwarz, but this is what is being done
already... although I used IP address in the examples the actual ftp
control-card member already addresses via name, such as remote-primary
and remote-backup. This is done for ease of maintenance, of course, but
I am working under the assumption of *minimal* communications on *all*
sides:
Out in a warehouse, somewhere on an old, plank road in the bowels of
Spider Crotch, Tennessee, one dark and stormy night, the C: drive of the
primary NT box begins to make noises... eventually it yowls like the
Disk of the Baskervilles and follows the Ancient examples set by the
Patriarch Abraham (Gen 25:8) and the Christ (Mark 15:37). The locals
are panic-stricken until Ol' Charlie - roused from his Pabst-induced
stupor and rousted from his comfortable bed on an unused bit of
shelving, away in the back next to the dust-covered cases of pickled
pigs-feet and vinegar-preserved hard-boiled eggs - fires up a Pall Mall
(stale, of course), exhales a plume of smoke and belches forth 'Whassa
pro'lem here? Ain't they give us a backup jes' fer times like this?'
A tentative finger pushes the Big Red Switch on the secondary device and
lo!... the familiar sequence of booting-up calms the crowd. The machine
comes to full life and - Saints be Praised, Faith 'n Gomorrah! - it has
a screen that looks *just* like the primary machine, even down to the
Download Orders icon! Ol' Charlie stumbles back to his shelf while a
Young'un takes charge, reasoning that if the icon on the backup looks
just like the icon on the primary then it should *act* just like the
icon on the primary... double-click on it and the Order-File will come
a-rumblin' down from the mainframe, ready for processing by the NT's
software.
You see, Mr Schwarz... no updating DNS, no renaming... just an
ever-constant state of readiness, in case a scenario such as this one -
and we *all* know how *utterly* unlikely such a scenario is! - might
occur.
DD
Thane Hubbell
>As does *any* 'real programmer', M Bernier, I wear boots - in my case they
>are (usually) well-polished boots of the kind issued to me when I enlisted
>in the Air Force Reserves, lo, those many decades ago - while coding; I
>find that these quite nicely permit my hands to work and prevent folks
>from dealing with the rampant confusions which might be cause by my...
>
>... programming feet.
Ok. I think I can find your cube now. Look for the one with the
highly polished boots set aside, and the dual keyboards - one for the
hands and one for the programming feet.
The Goobers
Exactly, Mr Hubbel! This is why I've frequently said to folks 'Oh, I'm
*easy* to find... just follow the smell!'
DD
Thane Hubbell
>First off, I tried to read as many of the replies to your request as my
>patience would allow.
>
>
>Here is my 2 bits.
>
>First FTP'ing directly to the internal reader is a very dangerous thing. It
>bypasses security protocols which most mainframers are forced to submit to.
>From your explanation it sounds like you are one of those PC/Mainframe
>Stealth programmers who bypass production control by FTP'ing directly to the
>internal reader. Not that I am putting you down, but that is a very
>dangerous thing to do. It is a major violation of security, especially if
>your FTP connection is open to the Internet.
This is getting far afield from the original query, but something in
your post made me sit up straight and recognize something I have seen
again and again.
I high security environments, users, programmers, and the like, do
whatever they can to not offend ye RACF gods, (who think themselves to
be God) and work AROUND the security. I happen to work on 2
mainframes presently - at opposite ends of the security spectrum. One
has 5 people I have to go through in order to ask permision to think
about asking permision for a change in security.
The other lets me do as I please when I please how I please.
On which system do you think I am the most productive?
Heck for compiles and such on the High security system, there is a set
of procedures designed by the staff in order to circumvent the
obviously too anal security in use. This has evolved over time - with
the workers working to work, and the security specialists working to
prevent the works form seeing anything their work does. It CAN become
Insane.
To that end, I DO regulary FTP directly to an internal reader,
directing the job to yet another system attached to this austere,
pristine, and oh so secure system.
Ron Schwarz -- see sig to reply
What I'd do if I were running the show (and I am *not* complaining that the
honor has not landed on my doorstep), is have each machine nudge the big iron
when it powers up, and have the big iron say to itself, "Hmmm, looks like it's
time for me to update yonder DNS table," the instant it feels the nudge.
The Goobers
And the advantage to constantly updating said DNS table instead of
attempting tp ftp to a backup IP address *if and only if* the ftp to the
primary IP address might be, in your opinion... ?
DD
Jeff
>directing the job to yet another system attached to this austere,
>pristine, and oh so secure system.
Without fear of upsetting the System RACF Lords....I would like to see an
example of FTPing to an internal reader. Can you send me one?
Ron Schwarz -- see sig to reply
Hmm... I may have misunderstood some of the basic premise. (and the last
sentence above doesn't seem to parse (using my coffeestarvedbrain), so I'll
guess at filling in the blanks.
You only want to send orders to the correct machine? The request is initiated
*by* the client?
If the request is initiated by the client, it shouldn't be hard to know where to
send the results. As to constant DNS updates, it seems to work OK for ML.ORG.
<g> (check out www.dyn.ml.org sometime)
In fact, come to think of it, that might be the answer. Have the FTP go to a
fixed address (not main, not backup, just a single address) and have each
machine register *that* address at dyn.ml.org when it comes on line.
The Goobers
No need for that... I'll just re-state the question:
What do you see as the advantage of constantly updating the DNS table,
as you suggest, instead of attempting an ftp to the backup IP address *i
and only if* the ftp to the primary fails?
>
> You only want to send orders to the correct machine? The request is initiated
> *by* the client?
So far, so good.
>
> If the request is initiated by the client, it shouldn't be hard to know where to
> send the results. As to constant DNS updates, it seems to work OK for ML.ORG.
> <g> (check out www.dyn.ml.org sometime)
I assume you mean http://www.dhs.org/ ... but, be that as it may...
>
> In fact, come to think of it, that might be the answer. Have the FTP go to a
> fixed address (not main, not backup, just a single address) and have each
> machine register *that* address at dyn.ml.org when it comes on line.
Ummmm... I cannot speak with any certainty but I believe that all IP
addresses are *internal* to the organisation.
DD
Steve Dover
>
> Alan Maitland <AMai...@NBCI.Net> wrote:
> >
> >Is there a utility on the mainframe that can PING an IP address and set up a
> >JCL variable that would ack or nak the ping?
>
> it (doc?... who has doc?) shows that unless I find out how to send
> multiple PINGs (a PARM someplace?) it only sends one... and I wouldn't
> want to direct my processing based on a single failed PING.
>
able to direct PING to perform multiple attempts, but the problem
with PING is that it is too low-level. I've encountered the
situation where a PING was successful, but otherwise the target box
was NOT usable.
>
> A slight variation is being implemented, as suggested by Mr Hubbel; an FTP
> will be attempted to the Primary and only if that fails will one be made
> for the Backup.
>
the FTP failing but the Primary box is really still usable.
I'd attempt the FTP to the Primary box at least two times before
switching over to the Secondary (since it may not be primed).
Murphy *is* watching you know. I'll give him a week <g>
--
Are you ready for year MM?
The Mother of all Messes.
285 Days to go before 'Ignorance is bliss' is obsolete.
news:comp.software.year-2000 Come for the signal, stay for the noise.
Steve Dover
>
[big snip]
>
> Ummmm... I cannot speak with any certainty but I believe that all IP
> addresses are *internal* to the organisation.
>
to the Internet. What you are referring to as internal are probably
incorrect class C addresses that are kept separate from the rest of
the Internet by a firewall. As long as you do not have to cross
a firewall with the application being discussed, you should have
no problems. But, if sometime in the future, the client does want
to use the Internet proper for the delivery of this data, then they
will be looking at a VPN (Virtual Private Network) and the applications
procedures may very well have to change. For now, KISS comes to mind.
The Goobers
>
> docd...@clark.net wrote:
> >
> > Alan Maitland <AMai...@NBCI.Net> wrote:
> > >
> > >Is there a utility on the mainframe that can PING an IP address and set up a
> > >JCL variable that would ack or nak the ping?
> >
> > Hmmmm... there is a PING program, similar to the FTP; diddling about with
> > it (doc?... who has doc?) shows that unless I find out how to send
> > multiple PINGs (a PARM someplace?) it only sends one... and I wouldn't
> > want to direct my processing based on a single failed PING.
> >
> DD, don't mess with PING, single PING or not.
Sold!
> You should be
> able to direct PING to perform multiple attempts, but the problem
> with PING is that it is too low-level. I've encountered the
> situation where a PING was successful, but otherwise the target box
> was NOT usable.
Say no more... rather than add a step which I don't quite understand and
for which there is minimal support and no doc... consider it 86'd.
>
> >
> > A slight variation is being implemented, as suggested by Mr Hubbel; an FTP
> > will be attempted to the Primary and only if that fails will one be made
> > for the Backup.
> >
> Don't forget the case of intermittent problems that result in
> the FTP failing but the Primary box is really still usable.
> I'd attempt the FTP to the Primary box at least two times before
> switching over to the Secondary (since it may not be primed).
Hmmmmm... so you'd suggest *four* ftp steps in total... first to the
Primary, second to the Primary if the first doesn't return 0000, third
to the secondary if second is executed *and* doesn't return 0000, fourth
if the third does likewise.
Belt and suspenders, aye.
>
> Murphy *is* watching you know. I'll give him a week <g>
Your Murphy is *remarkably* prompt.
DD
Ron Schwarz -- see sig to reply
>The Goobers wrote:
>>
>[big snip]
>>
>> Ummmm... I cannot speak with any certainty but I believe that all IP
>> addresses are *internal* to the organisation.
>>
>Actually, all IP addresses are unique if you are truly connected
>to the Internet. What you are referring to as internal are probably
>incorrect class C addresses that are kept separate from the rest of
There are two (or is it three?) blocks of addresses that are officially
forbidden to be exposed to the Internet (i.e., 192.168.*.*). These blocks are
reserved for private networks, and will never resolve via outside DNS (i.e.,
InterNIC).
>the Internet by a firewall. As long as you do not have to cross
>a firewall with the application being discussed, you should have
>no problems. But, if sometime in the future, the client does want
>to use the Internet proper for the delivery of this data, then they
>will be looking at a VPN (Virtual Private Network) and the applications
>procedures may very well have to change. For now, KISS comes to mind.
When he says that the IP addresses are internal to the organization, I assume
he's talking about a private network using reserved addresses. If they already
have an *actual* private network, they're probably going to be loath to consider
tunneling through a *virtual* private network.
mixx...@eye_eye_echs.com
> //STEPNUM EXEC PGM=FTP,PARM='100.100.100.1 (TIMEOUT 720 EXIT'
>
> Then on your next EXEC put a COND=(0,GT)
>
> Then the seocnd FTP won't go if the first one works.
>
Errr, does it really produce a negative number?
mixx...@eye_eye_echs.com
> Exactly, Mr Hubbel! This is why I've frequently said to folks 'Oh, I'm
> *easy* to find... just follow the smell!'
>
In point of fact, it is not uncommon around here to see a sock-footed
programmer or customer service rep' wandering around. One of my pairs
of boots is just a tad snug in the summer and at least once I went to
VP staff meeting while my footgear stayed under my desk.
I *would* ask anyone with gangrene to lay a little Lysol on 'em before
attending a closed-door conference!
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