IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

unknown DSS messages


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Jim Alton

New User


Joined: 31 Dec 2012
Posts: 31
Location: England

PostPosted: Fri Apr 12, 2013 3:25 pm
Reply with quote

I used JEM to check JCL and it's giving messages that I can't find any information on.
The following is a SYSIN statement from an IDCAMS step:

DELETE TESTQC99.&SYSUID..PRODGP15.UI.DAC10201.RESTART PURGE
***ERROR - DSS5595E - VALUE IS TOO LONG

and this if from a DD statement:

DSN=TESTQC99.&SYSUID..PRODGP15.UI.DAC10201.RESTART
DSN=TESTQC99.L5JALTO.PRODGP15.UI.DAC10201.RESTART

***ERROR - DSS4500E - INVALID DATA SET NAME FORMAT IN DSN= OPERAND

I would guess what is happening here is that the DSN is over 44 characters long - I presume this is still a limit - and JEM is trying to tell me that in different ways. Note that JEM resolved the DD DSN but not the SYSIN name.

I spent quite some time looking for DSS (Data Storage System?) messages but to no avail - i.e. DSSnnnna messages.
I looked at LookAt (http://www-03.ibm.com/systems/z/os/zos/bkserv/lookat/) for instance but also elsewhere. When I saw a list of message manuals I gave up since there doesn't seem to be any documented DSS messages, as implied by these message titles:

SA22-7634 z/OS MVS System Messages, Vol 4 (CBD-DMO)
SA22-7635 z/OS MVS System Messages, Vol 5 (EDG-GFS).

Can anyone say differently or tell me that the messages above aren't complaining about the length of the DSN?
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Fri Apr 12, 2013 3:34 pm
Reply with quote

The dataset name is 45 characters long - not allowed

I would assume and hope that the relevent messages are documented in the product manuals
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri Apr 12, 2013 3:57 pm
Reply with quote

Thanks for counting expat, I didn't see the resolution of the symbol :-)

The DSS are the messages from JEM.

I didn't realise that this would be a valid, catalogued, DSN:

Code:
A.B.C.D.E.G.H.I.J.K.L.M.N.O.P.Q.R.S.T.U.V.W


Used to be just five allowed :-), max of 8, with the full-stop/period separator, giving 44.

Now you can have 22, with the minimum length of one, and unable to use the full 44 characters. Live 'n learn.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Fri Apr 12, 2013 4:01 pm
Reply with quote

ADRDSSU aka DFDSS messages start with ADR

DSS.... messages are NOT IBM messages , speak to Your support.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Fri Apr 12, 2013 4:17 pm
Reply with quote

FYI: The DSS messages are probably coming from JEM/JOBSCAN.
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India

PostPosted: Fri Apr 12, 2013 5:45 pm
Reply with quote

Bill Woodger wrote:
Now you can have 22, with the minimum length of one, and unable to use the full 44 characters. Live 'n learn.
With z/OS 01.11.00, PDF 6.1 it fails for the DSN name you show. Possibly by "now" you're talking about z/OS > 1.11?
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri Apr 12, 2013 6:29 pm
Reply with quote

Well, not newer.

Code:
IEF285I   A.B.C.D.E.G.H.I.J.K.L.M.N.O.P.Q.R.S.T.U.V.W  CATALOGED


This is using IEFBR14, so I'd expect it to work for any DD statement in a JCL deck. Haven't tried it any other way.

z/OS V1R11 DFSMS Using Data Sets
wrote:
A data set name can be from one to a series of twenty-two joined name segments. Each name segment represents a level of qualification. For example, the data set name DEPT58.SMITH.DATA3 is composed of three name segments. The first name on the left is called the high-level qualifier, the last is the low-level qualifier.
Each name segment (qualifier) is 1 to 8 characters, the first of which must be alphabetic (A to Z) or national (# @ $). The remaining seven characters are either alphabetic, numeric (0 - 9), national, a hyphen (-). Name segments are separated by a period (.).
Data set names must not exceed 44 characters, including all name segments and periods.


The "now" I was referring to was against when I first used MVS :-)
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India

PostPosted: Sat Apr 13, 2013 11:02 am
Reply with quote

My bad Bill... icon_redface.gif. I must have had a brain failure while writing the previous post. Got it now - I'll walk like my avatar now.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Sun Apr 14, 2013 8:25 am
Reply with quote

Overheard one of your co-workers ask "Why is Anuj walking like that?" icon_cool.gif
Back to top
View user's profile Send private message
Jim Alton

New User


Joined: 31 Dec 2012
Posts: 31
Location: England

PostPosted: Fri Apr 26, 2013 2:34 pm
Reply with quote

This is a belated entry that I composed over a week ago but wasn't able to post it because of logon problems.

The DSS messages are not from IBM but, on our system, reside in a non-system PARMLIB, the member being DSSMSG00, and the parmlib is coded in all of the JCL checker objects (CLISTS).
In SYS1.TSOCMDS we have these JCL checkers: JEM, JSCAN, and JOBSCAN; and if you look at the programs called in these members, and browse the programs in the loadlib (also mentioned in the TSOCMDS members) then you’ll see that the organisation mentioned in the load members is the Allen Systems Group, Inc., also known as ASG Software Solutions, 1333 Third Avenue South, Naples, FL 34102. A bit more digging reveals that this company bought out another: “June 12, 2006 -- ASG, an enterprise software provider to Global 5000 companies, today announced it has sealed a deal to acquire Diversified Software Systems, Inc. (DSSI), a leading provider of JCL automation software products and services based in Morgan Hill, California.” (DSSI is defunct but one can still find current references for DSSI Inc., for instance in the Cortera Business Directory, but the address given (and using Google Maps) is clearly another company: Dividend Homes, 385 WOODVIEW AVE, STE 50, MORGAN HILL, CA, 950372891 US.). With DSSI as the original developer, it doesn’t take a rocket scientist to figure out where the DSS prefix in the messages comes from.
In SYS1.TSOCMDS the three JCL checkers refer to the following programs, and the provenance of the programs can be discovered by browsing:
JOBSCAN calls J00YDMU, which is credited to ASG, Inc., 2009;
JSCAN, in a section commented with “ALLOCATE RUN CONTROL LIBRARY”, calls J00YCKAL, which is credited to DSSI, Inc., 1995; and in a section commented with “RUN JOB/SCAN” it calls J0AYEMU, which is credited to ASG, Inc., 2008;
JEM, in a section commented with “ALLOCATE RUN CONTROL LIBRARY”, calls J00YCKAL, which is credited to DSSI, Inc., 1995; and in a section commented with “CALL THE JEM SUPERVISOR” it calls J0AYEMU, which is credited to ASG, Inc., 2008.

One last thing – on ASG's website they state:

“ASG-JOB/SCAN, a JCL validation and standards enforcement product, is specifically designed to help single LPAR data centers (with COBOL or Assembler expertise for JCL standards programs) operate an error-free production JCL environment. If your organization's data resides on a single LPAR, ASG-JOB/SCAN will validate the production JCL – processing the entire JCL jobstream, resolving backward references, substituting symbolics, applying overrides, and then evaluating each statement for accuracy according to standard z/OS syntax rules.”

I'm not au fait with LPARs (I think they’re a bit like Apple's BOOTCAMP in OS X 10.6 – i.e. a hardware division of the machine enabling multiple OS's), but don't most (or, at least, many) IBM installations run multiple LPARs? And what is the issue with restricting the scanning software to one LPAR? If LPARS are like Apple's BOOTCAMP then there will be separate system software for each LPAR, so, for instance, a separate Master Catalog; hence, logging on to a system with LPARs is like logging on to a single system,except there could be sharing of volumes, hence data, in multiple LPAR systems. But, of course, sophisticated techniques would be used to handle simultaneous requests for the same data, so what's the problem - is the statement correct on the point of only being able to operate in a single LPAR system (which I take to mean an undivided hardware system)?

P.S. An afterthought: when you look through the DSS messages they tell you which actual IBM message has been returned, and a DSS message can be associated with many IBM messages. But the scan will have been returned a specific IBM message, so why doesn't the scan display the actual IBM message – is ASG contractually prevented or is a message usage royalty to be paid?

P.P.S. The DSS messages can be expanded by issuing the command: JMSG line tag, e.g. JMSG .JAAA.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts REXX GETMSG does not return £HASP880... CLIST & REXX 2
No new posts Read 4MB message and split into multi... COBOL Programming 9
No new posts Suppress messages from being written ... All Other Mainframe Topics 6
No new posts Copy records with unknown LRECL DFSORT/ICETOOL 8
No new posts Web Service VS MQ Messages All Other Mainframe Topics 1
Search our Forums:

Back to Top