Cobol switches and LNM$FILE_DEV : bug ? - VMS

This is a discussion on Cobol switches and LNM$FILE_DEV : bug ? - VMS ; Cobol switches (see the SET SWITCH primitive) have been implemented with a logical name, COB$SWITCHES, normally defined in the process table at user level. For a reason unknown to me, the COBRTL code uses the first table pointed by LNM$FILE_DEV ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Cobol switches and LNM$FILE_DEV : bug ?

  1. Cobol switches and LNM$FILE_DEV : bug ?

    Cobol switches (see the SET SWITCH primitive) have been implemented
    with a logical name, COB$SWITCHES, normally defined in the process
    table at user level. For a reason unknown to me, the COBRTL code
    uses the first table pointed by LNM$FILE_DEV to create this logical
    name. This is OK until LNM$FILE_DEV is modified for whatever reason.
    If, after modification, the first table pointed by LNM$FILE_DEV belongs
    in LNM$SYSTEM_DIRECTORY, the user mode definition trick does not work
    and COB$SWITCHES remains defined after image exit, which is in complete
    contradiction to what is said about it in the compiler documentation.
    Does that count as a bug ? If yes, how do I get it solved ? And is
    there a way, documented or not, to force COBRTL to define COB$SWITCHES
    in LNM$PROCESS, whatever LNM$FILE_DEV says ?

    Thanks in advance,


    --
    Marc Van Dyck



  2. Re: Cobol switches and LNM$FILE_DEV : bug ?


    "Marc Van Dyck" wrote in message
    news:mn.bd367d893beae4b1.86952@brutele.be...
    > Cobol switches (see the SET SWITCH primitive) have been implemented
    > with a logical name, COB$SWITCHES, normally defined in the process
    > table at user level. For a reason unknown to me, the COBRTL code
    > uses the first table pointed by LNM$FILE_DEV to create this logical
    > name. This is OK until LNM$FILE_DEV is modified for whatever reason.
    > If, after modification, the first table pointed by LNM$FILE_DEV belongs
    > in LNM$SYSTEM_DIRECTORY, the user mode definition trick does not work
    > and COB$SWITCHES remains defined after image exit, which is in complete
    > contradiction to what is said about it in the compiler documentation.
    > Does that count as a bug ? If yes, how do I get it solved ? And is
    > there a way, documented or not, to force COBRTL to define COB$SWITCHES
    > in LNM$PROCESS, whatever LNM$FILE_DEV says ?


    A similar issue was reported back in 2004 (fixed for V8.2 and beyond) where
    some piece of code added a non-writeable table to the beginning of
    LNM$FILE_DEV causing the SET SWITCH to fail. After the change, if the
    initial sys$crelnm fails with LNM$FILE_DEV, the COBOL RTL falls back and
    uses LNM$PROCESS. (I didn't do that change - I wasn't involved with COBOL
    then).

    I'm also at a loss why we'd want a /USER definition of COB$SWITCHES in any
    other table than LNM$PROCESS since we want the logical to evaporate at image
    run-down.

    I'll add it to our list. In the meantime, as I noted above, the only way to
    influence the decision is to put a non-writeable table at the front but that
    is likely to screw up lots of other pieces of code so I wouldn't do that.

    John






  3. Re: Cobol switches and LNM$FILE_DEV : bug ?

    In article , Marc Van Dyck writes:
    > Cobol switches (see the SET SWITCH primitive) have been implemented
    > with a logical name, COB$SWITCHES, normally defined in the process
    > table at user level. For a reason unknown to me, the COBRTL code
    > uses the first table pointed by LNM$FILE_DEV to create this logical
    > name. This is OK until LNM$FILE_DEV is modified for whatever reason.
    > If, after modification, the first table pointed by LNM$FILE_DEV belongs
    > in LNM$SYSTEM_DIRECTORY, the user mode definition trick does not work
    > and COB$SWITCHES remains defined after image exit, which is in complete
    > contradiction to what is said about it in the compiler documentation.
    > Does that count as a bug ? If yes, how do I get it solved ? And is
    > there a way, documented or not, to force COBRTL to define COB$SWITCHES
    > in LNM$PROCESS, whatever LNM$FILE_DEV says ?


    Changing LNM$FILE_DEV to put the system table first is likely to
    break lots of things. The behaviour you're seeing is an expected
    result.


  4. Re: Cobol switches and LNM$FILE_DEV : bug ?

    John Reagan formulated on mercredi :
    > "Marc Van Dyck" wrote in message
    > news:mn.bd367d893beae4b1.86952@brutele.be...
    >> Cobol switches (see the SET SWITCH primitive) have been implemented
    >> with a logical name, COB$SWITCHES, normally defined in the process
    >> table at user level. For a reason unknown to me, the COBRTL code
    >> uses the first table pointed by LNM$FILE_DEV to create this logical
    >> name. This is OK until LNM$FILE_DEV is modified for whatever reason.
    >> If, after modification, the first table pointed by LNM$FILE_DEV belongs
    >> in LNM$SYSTEM_DIRECTORY, the user mode definition trick does not work
    >> and COB$SWITCHES remains defined after image exit, which is in complete
    >> contradiction to what is said about it in the compiler documentation.
    >> Does that count as a bug ? If yes, how do I get it solved ? And is
    >> there a way, documented or not, to force COBRTL to define COB$SWITCHES
    >> in LNM$PROCESS, whatever LNM$FILE_DEV says ?

    >
    > A similar issue was reported back in 2004 (fixed for V8.2 and beyond) where
    > some piece of code added a non-writeable table to the beginning of
    > LNM$FILE_DEV causing the SET SWITCH to fail. After the change, if the
    > initial sys$crelnm fails with LNM$FILE_DEV, the COBOL RTL falls back and uses
    > LNM$PROCESS. (I didn't do that change - I wasn't involved with COBOL then).
    >
    > I'm also at a loss why we'd want a /USER definition of COB$SWITCHES in any
    > other table than LNM$PROCESS since we want the logical to evaporate at image
    > run-down.
    >
    > I'll add it to our list. In the meantime, as I noted above, the only way to
    > influence the decision is to put a non-writeable table at the front but that
    > is likely to screw up lots of other pieces of code so I wouldn't do that.
    >
    > John


    We are still in V7.3-2 and our version of COBRTL stack-dumps when
    writing COB$SWITCHES in the first table pointed by LNM$FILE_DEV is
    not possible. We checked that by adding an ACL (ID=*,ACCESS=READ) to
    the table.

    Anyway, thanks for fixing that, even if it is not immediate. In the
    mean time, we have added yet another table, process-confined, in front
    of the offending one, and all is well again. I'd however like to get
    rid of this fix as soon as I can, as I imagine the face of my successor
    ten years ahead trying to understand why I ever did that...



    --
    Marc Van Dyck



  5. Re: Cobol switches and LNM$FILE_DEV : bug ?

    Bob Koehler laid this down on his screen :
    > In article , Marc Van Dyck
    > writes:
    >> Cobol switches (see the SET SWITCH primitive) have been implemented
    >> with a logical name, COB$SWITCHES, normally defined in the process
    >> table at user level. For a reason unknown to me, the COBRTL code
    >> uses the first table pointed by LNM$FILE_DEV to create this logical
    >> name. This is OK until LNM$FILE_DEV is modified for whatever reason.
    >> If, after modification, the first table pointed by LNM$FILE_DEV belongs
    >> in LNM$SYSTEM_DIRECTORY, the user mode definition trick does not work
    >> and COB$SWITCHES remains defined after image exit, which is in complete
    >> contradiction to what is said about it in the compiler documentation.
    >> Does that count as a bug ? If yes, how do I get it solved ? And is
    >> there a way, documented or not, to force COBRTL to define COB$SWITCHES
    >> in LNM$PROCESS, whatever LNM$FILE_DEV says ?

    >
    > Changing LNM$FILE_DEV to put the system table first is likely to
    > break lots of things. The behaviour you're seeing is an expected
    > result.


    As far as I know, changing LNM$FILE_DEV is perfectly supported,
    documented, and not explicitely forbidden by H.P. There are a lot
    of reasons - I have encountered many myself previously - why you
    would want to do that. And in any case, it's not me who's doing
    that, but a third-party product.

    --
    Marc Van Dyck



  6. Re: Cobol switches and LNM$FILE_DEV : bug ?

    In article , Marc Van Dyck writes:
    >
    > As far as I know, changing LNM$FILE_DEV is perfectly supported,
    > documented, and not explicitely forbidden by H.P. There are a lot
    > of reasons - I have encountered many myself previously - why you
    > would want to do that. And in any case, it's not me who's doing
    > that, but a third-party product.


    Yes it is, and I've used it, too. But just to add user defined
    group writeable tables in between job and group. HP doesn't
    EXPLICITLY forbid you from doing a "delete [...]*.*;*" from a
    system root directory such as SYS$SYSDEVICE:[SYS03], but I've
    actually seen the results of those foolish enough to do it.

    I do think COBOL should not implement its switches this way, but
    I also expect you can break other things if not carefull.


+ Reply to Thread