Bill Woodger

Good spot Gerard. That's the problem with comments. They aren't compiled, executed and tested, so only humans can spot when they are wrong...

I agree with Steve. LINKAGE SECTION. 01 something PIC X. PROCEDURE DIVISION USING something. MOVE something ( 1 : 20 ) TO somewhereelse MOVE something ( 1 : some20fromws ) TO somewhereelse The first MOVE is a compile error. The second is... down to the behaviour of the compiler. In Enterprise COBOL up to V4.2, it did the MOVE "correctly" (moved 20 bytes in this case). Initially with the new V5+ (rewrite of code-generation and optimisation) the behaviour changed. However, this cause too many problems,...

Hi Michael, welcome. COBOL programs have an overarching structure of four DIVISIONs: IDENTIFICATION (or ID if you are able) DIVISION, where you put all the stuff to "identify" the program, which these days needn't be much. PROGRAM-ID is just the name of the program; ENVIRONMENT DIVISION, where you establish the conditions under which the program is going to run, including connecting internal files to external files; DATA DIVISION, where all data is defined; PROCEDURE DIVISION, where you write all...

Awsome thanks alot guys. Tried the export COB_PRE_LOAD = functions and it worked. hello.cob IDENTIFICATION DIVISION. PROGRAM-ID. hello. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 01 WS_KEY PIC X(20). 01 WS_VALUE USAGE BINARY-SHORT SIGNED. PROCEDURE DIVISION. initialize WS_KEY. string "gri" delimited by size, low-value delimited by size into WS_KEY CALL "MapExample" USING BY reference WS_KEY RETURNING WS_VALUE. DISPLAY WS_VALUE. STOP RUN.

Yes, but perhaps someone faced with 3000 stand-alone programs using PARM might shy away from GnuCOBOL if they had to change them all just for that... A general program which just "pretends to be the OS" and does a (dynamic) CALL with the PARM data correctly formatted (from whatever source is required) would be one way to deal with it without 3000 program changes. PARMDD is very interesting. You could use one record of 32760 bytes (there's a caveat) to provide 32760 bytes of data. Or you could use...

For IBM Mainframe MVS or zOS, if no PARM (or PARMDD) data exists in the JCL, the 16 bit signed integer length of the PARM data will be zero. http://ibmmainframes.com/viewtopic.php?t=15326&highlight=parm+linkage+cobol As Bill Woodger explained, PARM (or PARMDD) data is a single character string, conceptually like a punch card. PARM data could be 0 to 100 bytes long, and PARMDD data could be 0 to 32,760 bytes long. If the LINKAGE section record is 100 bytes or less, the program has no way to tell if...

A lump of data is passed. It is up to the program to make sense of it. "a,b,c,d" on the PARM= arrives as that value, prefixed by a two-byte binary indicating the length of the data (excluding the length of the length). Run-time options can also be specified in the PARM/PARMDD, separated by a forward-slash, and whether the COBOL parm-data is to the left of right of the slash depends on a run-time option. PARM="a,b,c,d/someruntimeoption" or PARM="someruntimeoption/a,b,c,d" would arrive to the COBOL...

:-) And then copy/paste to outside the structure and the code behaves differently...