Is SLEEP a better option ??

ramp_senti · New User Joined: 17 Mar 2006 Posts: 26

Hi,

I have a scenario where i need to run a cobol -program and based on the result , i need to decide my further course of action in a CLIST program which uses panels ( interactive mode ).
Basically the program will check whether a particular literal is found in a file or not.
I tried using the file directly in my clist using EXECIO command but the file is very huge and im unable to get the storage space needed for this operation.And i have tried the maximum available storage for my userid in TSO region.
Is SLEEP a better option to handle this case ?? or
Is there any other option ?? We cant invoke a interactive pgm from a batch job.

superk · Posted: Fri Jan 16, 2009 8:35 pm

Is SLEEP a better option than what? What does running a COBOL program or reading/processing datasets have to do with storage limitations within TSO?

ramp_senti · New User Joined: 17 Mar 2006 Posts: 26

I thought of reading the file in my clist program itself to match the literal, but since the file is huge its running in the range of 5000 Mb .. and i'm unable to do an EXECIO operation to read the file because of the storage limitation.
Also i'm not sure if there is any other option other than using SLEEP ??

dbzTHEdinosauer · Posted: Fri Jan 16, 2009 9:08 pm

you are asleep at the wheel.

suggest you define your requirements - completely.

and stop trying to apply your preconcieved notions of a solution.

The only time I have seen a valid invokation of a 'sleep' was for a batch started task that ran 24/7. Sleep was used to help deal with -913's, etc...

why not CALL a cobol program from your REXX Script that would read the file and return a 'hit' or nofind situation.

I do not see a need for a delay in the scenario that you have not described.

ofer71 · Posted: Fri Jan 16, 2009 9:25 pm

If you want to find a string, then why can't you use SUPERC from within your CLIST?

O.

superk · Posted: Fri Jan 16, 2009 9:34 pm

... or call a simple SORT routine?

ramp_senti · New User Joined: 17 Mar 2006 Posts: 26

Dick,
Im automating a process which requires a set of jcls to be run. I need some parameters to be passed to the jcls.I'm getting this set of parameters from the user via a Panel (interactive mode). And now i need to validate the parameters entered by the user.For validating one of the parameter i need to check it against a file which is very huge.Now if the parm entered by the user is not found in the file i need to throw an error
message in the panel asking the user to enter a valid parm.

So to do this i need to read the file and do the validation. I'm unable to read the file in the REXX because of the storage limitaions ( My program abends with a message EXECIO : Unalble to obtain storage ).

I hope i'm clear here.

ramp_senti · New User Joined: 17 Mar 2006 Posts: 26

And when i use a cobol program or sort routine suggested by Kevin i cant invoke the rexx again from batch mode to display panel.

Pls let me know if i'm still not clear.

dbzTHEdinosauer · Posted: Fri Jan 16, 2009 9:56 pm

Fridays?
why not invoke the 'superc'/'sort'/'cobol' method of validating the parm from the REXX?????????????????????????????????????????

expat · Posted: Sat Jan 17, 2009 2:39 am

ramp_senti

Having seen the suggestions and advice offered by very experienced people, dare I ask, are you sure that your chosen profession is the correct one ?

superk · Posted: Sat Jan 17, 2009 2:52 am

The other piece of this puzzle that hasn't been made clear is why, if a REXX exec is not capable of doing what needs to be done, but a COBOL program is, is this process not coded in COBOL?

(not that I ever doubt the capabilities of a well-written exec).

ramp_senti · New User Joined: 17 Mar 2006 Posts: 26

I dont know wats the problem here !! Is it i'm not explaining well / or you folks not understanding the scenario / or me not understanding the one line solutions provided so far !!

Ill be happy if any of you can validate my understanding.

My understanding is this
* the storage available for the Execs is the storage available for your TSO session.
* One can't invoke a EXEC in a interactive mode displaying panels and receiving inputs from user from a batch program.

ramp_senti · New User Joined: 17 Mar 2006 Posts: 26

job !! not program

ramp_senti · New User Joined: 17 Mar 2006 Posts: 26

To EXPAT :
I guess Yes !! coz i haven't heard such a question so far from relevant folks !!

expat · Posted: Sat Jan 17, 2009 5:41 pm

I think that the problem is that many people have suggested that you are going in the wrong direction to resolve your issue, yet you are determined to follow that direction come what may.

Scenario - Your CLIST/REXX has submitted a job and there are processing problems or delays, and your submitted job sits waiting for an initiator for example 90 minutes. During this 90 minute period your terminal is locked and unusable for any other purpose.

You say a huge file, how many records and what is the LRECL. There are posts on the forum that deal with huge files using REXX. (I assume that your program is REXX as you say that your are using EXECIO). Did you use EXECIO to read the whole file, did you try to read only one record at a time, did you try processing blocks of records.

Have you considered using VSAM for your reference file, because you can invoke IDCAMS to select single or multiple key values and validate that way, rather than process a huge file. One or two reads and you are there.

Have you tried the suggestion of DBZ and invoking the sort or program from REXX/CLIST to see if that works ?

What is wrong with batch notification ? The job ends either sucessfully or not and issues a message to the user terminal with the return code. What about email notification from the job, either sucessful or not.

There are a good many years of experience on this forum from the senior members who have been there, seen that and have the T shirt to prove it. We are not having a pop at you personally, merely suggesting viable alternatives for your problem. Obviously at the end of the day if you choose to ignore or follow our suggestions is entirely up to you.

ramp_senti · New User Joined: 17 Mar 2006 Posts: 26

Eye opened Sir !!

I haven't tried the EXECIO to read a block of records !! Will try that !!Actually this is wat i was looking for !!

Actually somebody suggested this SLEEP but only after scanning the forum i learnt that SLEEP is not advisable !! just was looking for other options !!

Thanks a lot !!

MBabu · Posted: Sun Jan 18, 2009 4:02 am

Scenario sounds like it should be this. All done in Rexx exec.

Rexx starts and goes into display loop
Rexx issues ISPF display to get information and returns from display
Rexx does allocations for verification program and starts verification program using TSO's CALL or ISPF's SELECT service
Rexx examines return code from verification program and redisplays panel with a message if necessary or leaves display loop and continues

Note that there is no batch job involved here at all. Waiting on a batch job from an online program is a bad design. You can optimize this many ways, some of which have been suggested. Use a real data base instead of a sequential fiile, read the file once and keep keys in memory such as Rexx stem variable (use the keys as stem tails and check for the existence of the tail; don't save a separate tail for each record). Do the program calls from a Rexx panel exit (advanced and may not work but keeps the main rexx program from dealing with the problem). There are many designs possible but the more work you do up front , the less time the user will sit waiting at the terminal.

You can use EXECIO to read n records at a time instead of reading the whole file. That will fix the problem of running out of storage.

Douglas Wilder · Posted: Tue Jan 20, 2009 9:31 pm

dbzTHEdinosauer · Posted: Tue Jan 20, 2009 9:34 pm

to associate the word ONLINE with tso interactive panels is a stretch.
no, it is actually a mis-statement.

and as Mr. Wilder has mentioned, the need to execute a batch job and wait is not necessary.

You can invoke the cobol module directly from REXX.

MBabu · Posted: Wed Jan 21, 2009 5:11 am

While technically correct, it is a misstatement - the correct term is "foreground", though only because "online" is traditionally reserved for CICS and similar OLTPs. Though notice that even the acronym OLTP makes a distinction between the OL and TP part.

ramp_senti · New User Joined: 17 Mar 2006 Posts: 26

yeah i got ur point folks !!

I tried the Reading by block method and also the superc method ..but again the superc is taking around 3 mins time to complete the search ..

Is there any way to optimize the search ?? If needed ill paste the code also ..

ramp_senti · New User Joined: 17 Mar 2006 Posts: 26

Thanks Everyone !!

REPRO is working fast...in no time .. seems to be the right option ..