• David (unregistered) in reply to pitchingchris

    We used to receive a (large) daily file from a mainframe as recently as last year. It was fairly reliable but not 100%.

    The reliability got a lot worse when TPTB outsourced its support to India. The guys out there treated it like a small Windows server: if in doubt, reboot. Rebooting a mainframe is a LONG process...

  • Barf4Eva (unregistered) in reply to Yardik

    100% agree with #2.

    Why production code modifies a production DB table structure with DDL is beyond me... With that kind of mentality, I fear what other DDL statements are strewn about their code...

    On the other hand, it would be poor for me to assume what is the direct cause of the performance issue, although I could imagine any number of them with this code. I read a Dilbert cartoon that sums up assumptions nicely...

    http://www.dilbert.com/strips/comic/2009-08-30/

  • MrDee (unregistered)

    I don't know how and of the databases work but if one were to add a data item to a record wouldn't it require a new description and a data area? If there were 1,000 records that required a new data area so what? What if there were 10,000,000 records? DO these records each get moved to a new data area?

  • srm (unregistered)

    they are missing to check if the Mainframe table is populated at all with the needed information:

    SELECT 1 FROM dual WHERE EXISTS ( SELECT DISTINCT('MainFrameIsOn') FROM t WHERE EXISTS ( SELECT 1 FROM t WHERE MainframeOn = 1 ) )

    Without this check, the call to retrieve the value is overhead.

  • DavidL (unregistered)

    Suppose one of the gotchas there are the fact that the statement "ExecuteNonQuery("UPDATE [dbo].[Mainframe] SET MainframeOn = " & t)" will update every row in the table..

    Might take a while if the table is BIG..

  • DavidL (unregistered) in reply to DavidL

    But then again, that may be called "unreachable code"..

  • Bill (unregistered) in reply to srm
    srm:
    they are missing to check if the Mainframe table is populated at all with the needed information:

    SELECT 1 FROM dual WHERE EXISTS ( SELECT DISTINCT('MainFrameIsOn') FROM t WHERE EXISTS ( SELECT 1 FROM t WHERE MainframeOn = 1 ) )

    Without this check, the call to retrieve the value is overhead.

    cough what the hell is this bs? you could have stopped after the world "dual"...

    captcha luptatum

  • RobertoG (unregistered) in reply to Anonymous

    I have seen a crashed Unix machine that could be pinged but not loged on to. Ping is the first test level.

  • Bob (unregistered) in reply to RobertoG
    RobertoG:
    I have seen a crashed Unix machine that could be pinged but not loged on to. Ping is the first test level.

    agreed, ping is a silly idea,especially if it is a unix/linux box where the run level may be such that ping works but connections are refused to normal users.

    captcha damnum

Leave a comment on “Is the Mainframe On?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article