Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

File Status 39 on Open of Variable Length Dataset

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
akashprashant1

New User


Joined: 30 Apr 2007
Posts: 6
Location: India

PostPosted: Tue Feb 11, 2014 12:16 pm    Post subject: File Status 39 on Open of Variable Length Dataset
Reply with quote

Hi,

I am receiving File Status 39 while File2 (Variable Length) is being opened. Not sure how to resolve. Any help would be appreciated.

FD File2
Recording Mode Is V
Block Contains 0 Records
Label Records Are Standard.

01 File2-Record.
05 Out-Rec-Lgth-Qy PIC 9(04) COMP.
05 File2-Data.
10 File2-Record PIC X
Occurs 1 To 1689 Times
Depending On Out-Rec-Lgth-Qy.

//XXXXXXX DD DSN=XXXXXX. FILE2,
// DISP=(NEW,CATLG,DELETE),
// DCB=(MODLDSCB,LRECL=1697,RECFM=VB),
// SPACE=(TRK,(150,50),RLSE),UNIT=SYSDA


Thanks in advance.
Back to top
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Tue Feb 11, 2014 1:09 pm    Post subject: Reply to: File Status 39 on Open of Variable Length Dataset
Reply with quote

Check that the DDNAME shown is that which is used by that FD.
Back to top
View user's profile Send private message
akashprashant1

New User


Joined: 30 Apr 2007
Posts: 6
Location: India

PostPosted: Tue Feb 11, 2014 3:03 pm    Post subject: Re: File Status 39 on Open of Variable Length Dataset
Reply with quote

Found the root cause.

The FD entry has a PIC 9(4) COMP variable which takes 2 bytes. Therefore, 2 + 1689 + 4 (for VB datasets) = 1695. The LRECL value in my JCL had 1697 because I overlooked COMP. My job is working fine now.


Thank you!
Back to top
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1238
Location: Richfield, MN, USA

PostPosted: Tue Feb 11, 2014 8:20 pm    Post subject:
Reply with quote

MOST of the time (in MY experience) a 39 is the result of LRECL of the dataset does not match the record length defined in the program. Glad you found the error.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Wed Feb 12, 2014 4:06 am    Post subject: Reply to: File Status 39 on Open of Variable Length Dataset
Reply with quote

As a general rule, specifying PIC 9(08) COMP (a fullword) is a wiser choice for an OCCURS DEPENDING ON as it has a much greater maximum than a halfword, PIC 9(04) COMP and it's only two bytes more. Plus, COBOL has some rather strange idiosyncrasies when dealing with halfwords coupled with the TRUNC option.

If your compiler supports COMP-5 (as a substitute for COMP), then this is what you should use as binary-fields are treated correctly, because COMP-5 is Native Binary.

You'll sleep better.... icon_wink.gif
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Feb 12, 2014 5:56 am    Post subject: Reply to: File Status 39 on Open of Variable Length Dataset
Reply with quote

No, there are no idosyncracies with COMP fields and TRUNC. They work as documented.

COMP/BINARY/COMP-4 (IBM's Tom Ross has stated that the compiler code simpy aliases BINARY/COMP-4 to COMP) use decmal truncation. A PIC 9(4) of these has a maximum value of 9999.

COMP-5 is native binary, and only truncates to field-size. PIC 9(4) can contain 0-(64k-1).

COMP (and therefore its cousins) is affected by TRUNC.

TRUNC(BIN) and it is also native binary. The PICture is only used to define the field size (1-4, half-word, 5-9, fullord, more than 9, double-word).

TRUNC(STD) targets are always truncated to PICture (PIC 9(3) cannot contain more than 999).

TRUNC(OPT) is the one which needs understanding. To use TRUNC(OPT) all COMP field must conform to PICture. If they do not, then there is some foot-shooting in store. With TRUNC(OPT) the compiiler users whichever is more convenient (speedy) at the time, decimal or binary truncation. If the original source conforms to PICture, there is no problem.. Even if you "see" excess bits in intermediate values, they will not cause a problem. This, correct, behaviour is not limited to half-words.

COMP-5 is unaffected by TRUNC.

If the source is native binary (if it does not conform to PICture) use COMP-5, or you will potetially ose data.

There is a performance hit, generally, but not in all cases, from using COMP-5. Half-word COMP-5 is less problematic than full-word COMP-5 here.

Mess with addresses, use COMP-5. Needing to understand binary from an external source (JAVA, unix-type, Windows) use COMP-5.

So, know your data. If it conforms to PICture, use COMP. If it does not, use COMP-5.

Do not mix within or across programs/systems for the same data. Asking for trouble,

Defining everything as COMP-5 (or using TRUNC(BIN) will work, but there is that CPU hit. If someone decides later to change things for this reason, someone (else) will have to ensure that all binary fields conform to PICture or use COMP-5.

So, there are two choices for a value of >9999 and <32k, COMP-5 PIC 9(4) or COMP PIC 9(8) (not COMP PIC 9(9), which again has performance issues). Half-word instructions are cheaper than full-word instructions.

For >= 32k, COMP PIC 9(8) or COMP-5 PIC 9(9) (no similar problem with 9 "digits" for COMP-5, because COMP-5 is only using the "digits" to determine the size of the field).

All this is documented. There is nothing idiosyncratic. COMP-5 is not a Panacea.

Knowing your data is the important thing, then choosing something which can accurately represent all your data, and being aware of possiblle consequences of using binary fields many times.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Wed Feb 12, 2014 7:13 am    Post subject: Reply to: File Status 39 on Open of Variable Length Dataset
Reply with quote

Bill,

I've been bitten by the COBOL halfword issues many times in the past (when not COMP-5) and I always use fulllwords wherever possible.

As far as efficiencies, the difference is immeasurable.

That's all....
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Feb 12, 2014 2:06 pm    Post subject: Reply to: File Status 39 on Open of Variable Length Dataset
Reply with quote

OK, so what are the issues?

Immeasurable differences, no. I mentioned it because people notice it, and mentioned the "conversion" because people "convert" from it.

Making everything COMP-5 will work. There is a cost.

Making everything 9(9) for COMP-5 will work. There is a cost.

I just don't want someone making that into local law on the basis of "idiosyncrasies" which do not exist.

The costs are documented in the IBM Enterprise Performance Tuning guides. COBOL
Version 4 Release 2 is the latest, and with the least extreme of differences:

Quote:
TRUNC - BIN, STD, or OPT
When using the TRUNC(BIN) compiler option, all binary (COMP) sending fields are treated as either halfword, fullword, or doubleword values, depending on the PICTURE
clause, and code is generated to truncate all binary receiving fields to the corresponding halfword, fullword, or doubleword boundary (base 2 truncation). The full content of the field is significant.

This can add a significant amount of degradation since typically some data conversions must be done, which may require the use of some library subroutines.

BIN is usually the slowest of the three sub options for TRUNC.


The relative and absolute amounts of any differences depend, of course, on the specific programs/systems. If there is an element of charging based on CPU, ask the bill-payer the percentage (across a system(s)) they would refuse as a saving.

I've only quoted the one piece, because when I've pasted from the .PDF and it arrived a word at a time...

I have no problem with the suggestion to use COMP-5, only with the context of the suggestions.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Thu Feb 13, 2014 12:32 am    Post subject: Reply to: File Status 39 on Open of Variable Length Dataset
Reply with quote

Bill,

About 15 years ago, I was doing a lot of bit-twiddling using halfwords and one day, I got bit, when an overseas client had compiled our programs using TRUNC(STD) as opposed to TRUNC(OPT), which is what we had recommended and the result of the halfword bit-twiddling was incorrect and it caused a big mess.

I understand the additional overhead associated with TRUNC(BIN) as well as 9(09) fullwords. I always use 9(08) fullwords with TRUNC(OPT) or COMP-5 (second choice, when mandated). When defined as COMP-5, the TRUNC option has no effect (been conveying this for years), but there's additional overhead as COMP-5 is a trimmed-down version of TRUNC(BIN).

I would contest the difference between halfwords (9(04)) and fulllwords (9(08)) when using TRUNC(OPT) as the efficiencies are immeasurable and are not worth the time and effort. The main thing is that they are a friendly definition in COBOL as opposed to doubleword-binary, which historically is not.

Perhaps my experiences are out dated?

Maybe, but these are my personal choices, which I know will always keep me out of trouble (fool me twice, shame on me) and avoid those O'Dark Thirty phone calls. sterb050.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Add PD field from 2nd file to PD in 1st Sushant Garje DFSORT/ICETOOL 6 Thu Dec 01, 2016 4:32 pm
No new posts File Aid to File Manager conversion murali3955 IBM Tools 4 Thu Nov 24, 2016 3:41 pm
No new posts How to convert the VBM file to VB or... Sulabh Agrawal JCL & VSAM 4 Fri Nov 18, 2016 1:04 pm
No new posts FTP - JCL failed while passing FTP co... Suneetha1612 JCL & VSAM 12 Wed Nov 16, 2016 7:33 pm
No new posts CICS Roll back partially - Need to re... dwijadas CICS 4 Wed Nov 16, 2016 4:30 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us