Operating System - OpenVMS
1748180 Members
4119 Online
108759 Solutions
New Discussion юеВ

Re: Getting block size of a data file, from within COBOL.

 
SOLVED
Go to solution
Jan van den Ende
Honored Contributor

Re: Getting block size of a data file, from within COBOL.

Pallavi,

for many visitors in this forum, (those behind a strict ruled firewall, and those running M$ systems, others maybe) it is impossible, or impracticle, if teh appended text is anything else as ".TXT"
For future postings, please rename the file accordingly.

Thanks in advance.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Pallavi Akundi
Occasional Advisor

Re: Getting block size of a data file, from within COBOL.

Hello,

Sorry,I did not know about that.

Here is the .COB again renamed as .txt :)

Pallavi
People with goals succeed because they know where they are going-- as quoted by some one
Hein van den Heuvel
Honored Contributor

Re: Getting block size of a data file, from within COBOL.

Hi there Pallavi,

Welcome to the OpenVMS Forum.
Always good to see new names!

Unfortunately there are several issues with your proposed solution.

Most importantly a spawned process has its own symbol space which is not visible to the parent. You would have to define a LOGICAL, not a symbol, in the JOB table to get information from child to parent.

Actually... if you only need to return 1 integer value you can 'cheat' and return it as the status.

Minor problems
- diplay : typo
- moving spaces in command after setting text.
- command file need := to for string asssignment
- f$file: Why pass string with expanded variable if you can just pass the variable:
...f$file (file, "eof")
(Answer: because you want to see the text with 'set verify')

Try the following. It 'encodes' the size into a status to make it look succesful and have to OPTION (not done here) to detect failure.

$ type detsize.com
$FILE := tmp.exe
$FILE_SIZE == F$FILE_ATTRIBUTES("''FILE'","EOF")
$exit 2*file_size + 1

$Type test.cob
IDENTIFICATION DIVISION.
PROGRAM-ID. DETSIZE.
AUTHOR. PALLAVI.
ENVIRONMENT DIVISION.

INPUT-OUTPUT SECTION.

FILE-CONTROL.
I-O-CONTROL.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
01 SUBMIT-COMMAND PIC X(100).
01 FILE-SIZE PIC 9(9).
01 stat pic s9(9) comp.
PROCEDURE DIVISION.
MAINLINE.
MOVE SPACES TO SUBMIT-COMMAND.
STRING "@DETSIZE" DELIMITED BY SIZE
INTO SUBMIT-COMMAND.
CALL "LIB$SPAWN" USING BY DESCRIPTOR SUBMIT-COMMAND,
omitted,omitted,omitted,omitted,omitted, by reference stat.
subtract 1 from stat.
divide stat by 2 giving FILE-SIZE.
DISPLAY "--------- \ \ \ \ \ / / / /________".
DISPLAY "THE FILE SIZE IS:::" FILE-SIZE.
MAINLINE-EXIT.
EXIT.


(I needed cobol/ansi due to tab/spaces/whatever).

Hein.
Pallavi Akundi
Occasional Advisor

Re: Getting block size of a data file, from within COBOL.

Hello Hein,

Please ignore the typos (last min attaching of wrong file) But, thanks for elaborating on why we can't read the symbol back into the cob with lib$get_symbol.
But I did not get why we needed to do the
$exit 2*file_size + 1

Could we not have done it as

$exit file_size ?

Regards,
Pallavi
People with goals succeed because they know where they are going-- as quoted by some one
Hein van den Heuvel
Honored Contributor

Re: Getting block size of a data file, from within COBOL.

The 'odd' status is used to help testing the program and as a way to convey TWO flavors of data.

In VMS odd exit status values indicate success, even indicate a problem.

If the tool simply used the files size as exit, then how can it indicate a problem (for example: file-not-found)?

Looking at it from the other side, what if the file size is even (for example 12). Try it...
$ exit 12
%SYSTEM-F-ACCVIO, access violation,
That would be rather confusing no?
Did the process die a horrible death or was the size 12? Knowing that it is not a C program, but a DCL script and ACCVIO is very unlikely, so we 'guess' it is a size?
Now $exit 25 --> silence.

Cheers,
Hein.


John T. Farmer
Regular Advisor

Re: Getting block size of a data file, from within COBOL.

Thanks for the help from all who responded.