Fear of Foreground?

[John Dueckman]

"Back in the day", we used to highly restrict Endevor actions, especially "generates". After all, the idea of doing foreground compiles was HORRIFYING! "We can't let lowly developers do that! It will take up too much CPU time...."...

 

And so we restricted certain actions in certain processor groups to Batch-Only.... and condemned developers to submitting batch jobs for something as simple as ADD/UPDATE.... or maybe MOVE.... and, ok, DELETE too for a complete trifecta...

 

Now, this was in the day when 100 MIP machines were considered BIG THINGS! WOW! 100 MIPS! Talk about your processing power....

 

Compared to today, 100 MIPS could almost be considered an entry-level machine on a desktop!

 

So I'm curious.... how many sites (especially "legacy" sites) have circled back and reconsidered that old restriction/taboo on executing certain actions in foreground? Have we gotten over our "fear of foreground"?

[Philip Gineo]

Hi John, We still have foreground turned off. -Phil   

[Mathew Goldstein]

There is a problem with limited region size for TSO User sessions.  Object oriented compilers are being utilized more often than in the past, particularly with the new JAVA capability, and require a lot of memory.  Bigger machines quickly becomes bigger workloads on fewer machines.  TSO foreground will always be assigned high priority and workload balancing remains an issue, plus we want to take advantage of batch only features like AUTOGEN, concurrent processing, type sequencing, and skipping the generate action altogether after an edit.  Except for concurrency these features do not apply to delete actions, and delete actions are mostly offloaded to the DASD processing units, so entry stage developer initiated delete actions where no package is needed are good candidates for foreground.  Maybe one day we will have quantum mechanical processing units, then maybe we could reconsider batch.

[Phontilla Shuffitt]

John I have foreground turned off as well, because if there is an issue that is the best way an Endevor support/administrator can help the user. Because it never fails, if there are issues the novice user would exit out of Endevor and all of the information to help diagnosis the issue has been deleted.

 

And I highly agree with Mathew's statement above.  I believe that most of the time the developer prefers to make their changes outside of Endevor and then when they are ready to start performing testing against an executable, then they will add their source to Endevor (why I don't know), because afterall Endevor is ENvironment for DEVelop and OpeRations.... 

 

have a great day,

Phon

[SBAshby]

Hi John,

The Eclipse interface is a pseudo foreground.

It works well for the actions that would traditionally be batch.

Stuart 

[Steve Blackett]

We have a mixture and prefer people to use batch, although a lot of more "simple" events like add and moves that don't require complex generates like a COBOL compile are run by standard in foreground.

As Phon states and I agree - we don't like getting called out with "something went wrong with ENDEVOR" to then struggle to get the information from an end user. A batch job output removes this issue and it's another problem with the eclipse interface of how to actually see user logs when a problem occurs.

 

As Matthew states as well, if you're using features like CAP or AUTOGEN, batch is a prereq.

 

Unless a foreground option is pretty fast, why would you want to lock your TSO session?

So batch makes a lot of sense. z/OS is only a pseudo realtime OS.

 

I think complex realtime LEGACY compiles for ENDVEOR make no sense in the 21st century. The workload should be offloaded to your PC running an IDE and reported back to ENDEVOR if required.