COPY IDMS issues in COBOL

[Paul Schulz]

Development question; I have programmers that are changing their COBOL compile option from DYNAM to NODYNAM. In order to do this, they will need to continue calling some programs dynamically using what they call Call Identifier. Currently the code has Call 'Literal' (CALL 'DBDCS001' USING...) After doing some searching we found that the code in question is in IDMS being brought in with the following statement:

 

COPY IDMS DBDC-IDMS-RESTART-ROUTINE.

 

I have found this code in IDMS by running DIS MOD DBDC-IDMS-RESTART-ROUTINE. in IDD. I see the code in there and I think it would be smart to make the change. 

 

I have a couple questions:

1) Is this module custom code from my organization or does it come with IDMS?

2) The Display shows 40 or 50 programs that it is USED BY. I doubt that I need to get them all recompiled at once, but we need to be aware that the next time they recompile they will pick up this change. I am not sure that the same development team owns all of those programs.

 

Since I have to change the call to a Call Identifier, it makes sense that I would create that identifier in an include that is being used in this code. I have found the following statement that has some variables used in the Restart Routine. 

 

COPY IDMS SUBSCHEMA-CONTROL.

 

A couple more questions:

3) Where do I display this SUBSCHEMA-CONTROL? I can't seem to find it / don't know if it is a record or what.

4) Is this IDMS-supplied code? Is there any danger in making the change to it?

 

-paul

[Legacy User]

Well, let’s see if I can answer your questions:

 

COPY IDMS DBDC-IDMS-RESTART-ROUTINE.

COPY IDMS SUBSCHEMA-CONTROL.

 

1) Is this module custom code from my organization or does it come with IDMS?

           DBDC-IDMS-RESTART-ROUTINE is NOT a CA-IDMS supplied entity. You will need to maintain it yourself.

 

2) The Display shows 40 or 50 programs that it is USED BY. I doubt that I need to get them all recompiled at once, but we need to be aware that the next time they recompile they will pick up this change. I am not sure that the same development team owns all of those programs.

            You may be able to change this transparently depending on how you supply the variable name to be used in the CALL IDENTIFIER verb.

 

3) Where do I display this SUBSCHEMA-CONTROL? I can't seem to find it / don't know if it is a record or what.

            Check the DML Programmer’s manual:

            Copies both the SUBSCHEMA-CTRL and SUBSCHEMA-NAMES components. Do not specify SUBSCHEMA-CONTROL if the subschema's usage mode is LR.

            SUBSCHEMA-CONTROL is an entity known to the pre-compilers, It is not a construct in the dictionary.

 

4) Is this IDMS-supplied code? Is there any danger in making the change to it?

            Since the answer to #1 is that it isn’t IDMS supplied, you can do what you want.

            Since the answer to #3 is that the entity doesn’t exist, you can’t change it.

 

So, how can you change #1 and make it transparent.

Consider changing the record, SUBSCHEMA-CTRL.

You could define an element, let’s call it DBDCS001, and give it a picture of X(08) and a VALUE of DBDCS001.

Now, add this element TO THE END of the record SUBSCHEMA-CTRL.

Now, when a program is run thru the precompiler and SUBSCHEMA-CTRL is copied in, either manually or automatically, after the IDMS supplied definition you will find the element DBDCS001 defined and it will be properly defined for use in a CALL IDENTIFIER instruction.

 

So, what you have to decide is whether you want to modify the SUBSCHEMA-CTRL record in your dictionary.

 

The issue becomes, what happens when a new install is performed and the dictionary update steps are executed against the dictionary(ies) with your changes. Simple, the SUBSCHEMA-CTRL record will be updated and, I believe your element will remain intact. The updates to the record are MODIFY statements not DELETE/ADD combinations. CA can’t afford to do DELETE/ADD combinations because if they do, their clients lose all visibility to what programs have copied in the SUBSCHEMA-CTRL record into a program.

 

So, there’s one way.

Is there another, possibly, I’m not 100% sure.

 

Something else to consider is to create a new copy of SUBSCHEMA-CTRL in your dictionary with a version higher than any version IDMS supplies. Then, add you element (as above) at the end and use it in your programs. The only unknown here is, what happens when IDMS supplies a new version with new redefinitions of the existing elements? I don’t believe your customized version will be updated. Good? Bad? You’re call…

 

Those are my thoughts on your questions. They are my opinions, and mine only.

 

Good Luck,

Chuck

 

 

Charles (Chuck) Hardee<mailto:[e-mail]>

Senior Systems Engineer/Database Administration

EAS Information Technology<mailto:DBA%20Engineering%20-%20DB2_IDMS>

 

Thermo Fisher Scientific

300 Industry Drive | Pittsburgh, PA 15275

Phone [phone] | Mobile [phone] | FAX: [phone]

[e-mail]<mailto:[e-mail]>  | www.thermofisher.com

 

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent of a system responsible for delivering the message to the intended recipient, is prohibited. If you are not the intended recipient, please inform the sender and delete all copies.

[Tommy Petersen]

It does not appear that the module you have is delivered with IDMS.

 

 

When you specify copy idms subschema-control, the precompiler "copies in" a number of records.

subschema-ctrl

subschema-ss-name

subschema-recnames

subschema-setnames

subschema-areanames

Only subschema-ctrl is an actual record in the IDMS dictionary, the others are created based on the subschema.  I don't know if they are control blocks within the subschema or if they are dynamically created every time a compile is executed, but the fields and values in them are tied to the subschema source..

[Legacy User]

Tommy,

 

 

subschema-ss-name

subschema-recnames

subschema-setnames

subschema-areanames

are all created, dynamically, at compile time and are created based on the content of the subschema.

Essentially, they are all 16 byte fields each with a label appropriate to what they represent.

 

The recnames are all SRnnnn where nnnn is the assigned record number in the schema.

Setnames and Areanames are labeled with the entity name, that is the set or area name value, with a pic x(16) and value of the entity.

 

So, you would get something like this:

 

 

01     SR12345                               PIC X(16) VALUE ‘THE-RECORD-NAME’.

01   A-SET-IN-THE-SSC            PIC X(16) VALUE ‘A-SET-IN-THE-SSC’.

01   A-SSC-AREA                        PIC X916) VALUE ‘A-SSC-AREA’.

 

Chuck

 

Charles (Chuck) Hardee<mailto:[e-mail]>

Senior Systems Engineer/Database Administration

EAS Information Technology<mailto:DBA%20Engineering%20-%20DB2_IDMS>

 

Thermo Fisher Scientific

300 Industry Drive | Pittsburgh, PA 15275

Phone [phone] | Mobile [phone] | FAX: [phone]

[e-mail]<mailto:[e-mail]>  | www.thermofisher.com

 

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent of a system responsible for delivering the message to the intended recipient, is prohibited. If you are not the intended recipient, please inform the sender and delete all copies.