IDMS

  • 1.  FlashCopy with Quiesce and/or Exit 38

    Posted Mar 29, 2007 10:43 AM
    We are in the process (at long last) of converting our local mode batch
    jobs to run under CV. Our DASD is also being ported to an IBM DS8000
    Series Storage device with FlashCopy enabled.

    That should give us new options for DB backup and recovery! [IBM
    FlashCopy is supposed to create a quiesced 'copy' of the database files
    that can be used to create backups from and/or be used for DB recovery.]


    Does anyone have a process to obtain quiesced backups that they are
    wiling to share?

    Is anyone using the DCMT QUIESCE command to create quiesced DB backups
    with or without using EXIT 38 to initiate the backups?

    Is anyone using IBM DS8000 Series Storage units with FlashCopy to create
    DB backups?


    Jim Ritterbusch Mail:
    GE Capital Solutions 10 Riverview Dr.
    101 East Ridge Danbury, CT 06811

    T 203.749.3585 F 203.749.4016
    D 8*662.3585 E james.ritterbusch@ge.com
    http://www.ge.com/capitalsolutions/
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    FlashCopy with Quiesce and/or Exit 38
    "We are in the process (at long last) of converting our local mode batch
    jobs to run under CV. Our DASD is also being ported to an IBM DS8000
    Series Storage device with FlashCopy enabled.

    That should give us new options for DB backup and recovery! [IBM
    FlashCopy is supposed to create a quiesced 'copy' of the database files
    that can be used to create backups from and/or be used for DB recovery.]


    Does anyone have a process to obtain quiesced backups that they are
    wiling to share?

    Is anyone using the DCMT QUIESCE command to create quiesced DB backups
    with or without using EXIT 38 to initiate the backups?

    Is anyone using IBM DS8000 Series Storage units with FlashCopy to create
    DB backups?


    Jim Ritterbusch Mail:
    GE Capital Solutions 10 Riverview Dr.
    101 East Ridge Danbury, CT 06811

    T 203.749.3585 F 203.749.4016
    D 8*662.3585 E james.ritterbusch@ge.com
    http://www.ge.com/capitalsolutions/
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Debugging database procedures
    "Well, the area that you're saving to should not be in the program code.
    Why? Because if a database procedure is not fully reentrant, then it's
    useless. You can not store anything within a program and have it be
    reentrant. If the system is storage protected, you'll get an oc4. If
    the system is not storage protected, then you get unpredictable results.
    When in system mode you get working storage through a #getstk call or
    #getstg call, but get stack would be more efficient. This will carve
    out a working storage area out of the tce stack. A better approach is
    an ISA, as this comes out of the storage pool and not the stack, and
    furthermore the storage is acquired before the database procedure
    develops a problem, not after.


    Lutz Petzold


  • 2.  Re: FlashCopy with Quiesce and/or Exit 38

    Posted Mar 29, 2007 01:03 PM
    At 15:43 3/29/2007, you wrote:
    We are in the process (at long last) of converting our local mode batch
    jobs to run under CV.
    is that a good thing? I think LOCAL MODE has many advantages in the
    right circumstances ... your post made it sound like LOCAL MODE was
    some evil to be avoided at all cost ... why convert to CV MODE?


    This is Chris Hoelscher and I approved this email
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Debugging database procedures
    "Don,

    I was aware that IDMSDBMS did a check to see it the DB procedure starts
    with a #START macro.

    What it does if just a BALR R14,R15.

    I wrote a procedure some time back to figure this out. All the proc does
    is
    STM R14,R12,0(R13) No stack checking here!!!!
    BALR R12,0
    USING *,R12
    ST R14,SAVER14 SAVR14 is part of proc
    LM R14,R12,0(R13)
    BR R14

    Looking in memory R14 points into IDMSDBMS and the two 2 bytes before
    are X'05EF'.
    I believe it works this way to support procs written long before the
    #START and other macros where documented (or even written).

    I wrote procedures back in 4.5 days and do not remember things like
    #START being documented or if they existed.

    Pete