i've got a problem, that i can't resolve.
I want to try to work with IMS. so i make dbdlib, psblib, and now write jcl to init my db.
1://RELOAD EXEC PGM=DFSRRC00,PARM='ULU,DFSURGL0,LIBDBD,,,,,,,,,,,N'
2://STEPLIB DD DISP=SHR,DSN=DFSD10.SDFSRESL
3://DFSRESLB DD DISP=SHR,DSN=DFSD10.SDFSRESL
4://IMS DD DISP=SHR,DSN=USER19.DBDLIB
5://DFSUINPT DD DUMMY
6://DFSVSAMP DD DISP=SHR,DSN=DFSD10.PROCLIB(VSAMP01)
7://SYSPRINT DD SYSOUT=*
8://DATABASE DD DISP=OLD,DSN=USER19.LIBIMS
This is my jcl. I've got rc 16 and such msgs in sysprint:
DFS386A A PREMATURE EOF WAS ENCOUNTERED ON DDNAME DFSUINPT
DFS339I FUNCTION DR HAS COMPLETED ABNORMALLY RC=16
I think, he want me putting some data in my db, but i only want to init EMPTY db
I don't think that you should be using DFSURGL0 as that's reload/unload utility as per
The HD Reorganization Reload utility (DFSURGL0) reloads databases and HALDB partitions by using the output data sets that are created by the HD Reorganization Unload utility (DFSURGU0).
I'd suggest haveing a look at the IBM Knowledge centre. This could be a good starting point as it's the initialisation utilities. Definition and initialization utilities
I can't be of much more help as it's been around 30 years or since I last used IMS Utilities and only have access to search the web in this respect.
In brief terms what you've encountered is the utility saying it expects some data in the ddname DFSUINPT and DD DUMMY results in END of DATA (EOF) immediately the DDNAME is accessed/read. So DFSURGL0 is complaining, hence CC=16. Another way of looking at this is that you told it, perhaps by default, to load the database, so it's saying what with.
Related
When starting a job it fails with JCL not run
173 IEFC621| EXPECTED CONTINUATION NOT RECIEVED
174 IEFC605| UNIDENTIFIED OPERATIONAL FIELD
The code
173 //STEP1 EXEC SASDUP,WORKU=SYSDU,WORK='100,25'
OPTIONS='MACRO SORTDEV=SYSDU FS X
174 // SYSPARM=''''2016040120160430'''''
//STEP1 EXEC SASDUP,
// WORKU=SYSDU,
// WORK='100,25',
// OPTIONS='MACRO SORTDEV=SYSDU FS SYSPARM=''''2016040120160430'''''
This is just freehand, I haven't tested it.
As #BillWoodger indicates, continuation can be quite tricky.
So first, there's missing a coma after you "WORK='100,25'" parameter. Second, make sure your continuity of statement never starts after position(cols) 16. It may also be over or under 16 though, depending on your emulator (look were a wrote here below). Third, the issue could be into your SASDUP application. Fourth, clean up your OPTION and SORTDEV parameters? I don't think it can work like that.
OPTIONS='MACRO SORTDEV=SYSDU FS X
?
Take a look at SASDUP, it may help you found which parameters it needs. And so, parameters for SASDUP must be separated with comas and, if on the next line, must begin at a specific position.
Try something like that.
//STEP1 EXEC SASDUP,WORKU=SYSDU,WORK='100,25',
*here* OPTIONS='MACRO',SORTDEV='SYSDUFSX'
//*here* SYSPARM='2016040120160430'
I'm far from a expert, but I hope it'll help you.
The following space allocation is giving me an sB37 JCL error. The cobol size of the output file is 100 bytes and the lrecl size is 100 bytes. What do you think is causing this error? I have tried increase the size to 500,100 and still get the same error.
Code:
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DCB=(LRECL=100,BLKSIZE=,RECFM=FBM),
// SPACE=(CYL,(10,5),RLSE)
Try to increase not only the space, but the volume as well.
Include VOL=(,,,#) in your DD. # is the numbers of values you want to allocate
Ex: SPACE=(CYL,(10,5),RLSE),VOL=(,,,3) - includes 3 volumes.
Additionally, you can increase the size, but try to stay within reasonable limits :)
The documentation for B37 says the application programmer should respond as indicated for message IEC030I. The documentation for IEC030I says, in part...
Probable user error. For all cases, allocate as many units as volumes
required.
...as noted in another answer. However, be advised that the documentation for the VOL parameter of the DD statement says...
If you omit the volume count or if you specify 1 through 5, the system
allows up to five volumes; if you specify 6 through 20, the system
allows 20 volumes; if you specify a count greater than 20, the system
allows 5 plus a multiple of 15 volumes. You can override the maximum
volume count in data class by using the volume-count subparameter. The
maximum volume count for an SMS-managed mountable tape data set or a
Non-managed tape data set is 255.
...so for DASD allocations you are best served specifying a volume count greater than 5 (at least).
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DCB=(LRECL=100,BLKSIZE=,RECFM=FBM),
// SPACE=(CYL,(10,5),RLSE)
Try this instead. Notice that the secondary will take advantage of a large dataset whereas without that parameter the largest secondary that makes any sense is < 300. Oh, and if indeed it is from a COBOL program make sure that the FD says "BLOCK 0"!!!!! If it isn't "BLOCK 0" then you might not even need to change your JCL because it wasn't fixed block machine. It was merely fixed and unblocked so the space would almost never be enough. And finally you may wish to revisit why you have the M in the RECFM to begin with. Notice also that I took out the LRECL, the BLKSIZE and the RECFM. That is because the FD in the COBOL program is all you need and putting it in the JCL is not only redundant but dangerous because any change will have to be now done in multiple places.
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DSNTYPE=LARGE,UNIT=(SYSALLDA,59),
// SPACE=(CYL,(10,1000),RLSE)
There is a limit of 65,535 tracks per one volume. So if you will specify a SPACE that exceeds that limit - system will simply ignore it.
You can increase this limit to 16,777,215 tracks by adding DSNTYPE=LARGE paramter.
Or you can specify that your dataset is a multi volume by adding VOL=(,,,3)
You can also use DATACLAS=xxxx paramter here, however first of all you need to find it. Easy way is to contact your local Storage Team and ask for one. Or If you are familiar with ISPF navigation, you can enter ISMF;4 command to open a panel
use bellow paramters before hitting enter.
CDS Name . . . . . . 'ACTIVE'
Data Class Name . . *
It should produce a list of all available data classes. Find the one that suits you ( has enougth amount of volume count, does not limit primary and secondary space
I`m playing around with CLR Memory Diagnostics tool in order to analyze memory dumps.
Opening a dump using WinDBG, I am able to use .time command to get the debug session time (when dump was captured).
Does anybody knows the ClrMD API to get the date?
I've found the following way to solve this task, however it restricts us to the DbgEng usage only.
Open dump file and specify DbgEng (so IDebugClient will be used)
DataTarget.LoadCrashDump(pathToMemoryDumpFile, CrashDumpReader.DbgEng));
Use the IDebugControl2 COM interface to get target time (ensure that you perform that on the same thread that started the session):
uint secondsSinceUnix;
var dbgCtrl2 = (IDebugControl2)sessionContext.DataTarget.DebuggerInterface;
dbgCtrl2.GetCurrentTimeDate(out secondsSinceUnix);
Convert secondsSinceUnix to DateTime using the approach described here.
As output you will get UTC date time of the memory dump creation (or attaching time).
It worked well for me :)
I am trying to get familiar with gem5 simulator.
To start, I wrote a simple program with
int main()
{
m5_reset_stats(0, 0);
m5_dump_stats(0, 0);
return 0;
}
I compiled it with util/m5/m5op_x86.S and ran it using...
./build/X86/gem5.opt configs/example/se.py --caches -c ~/tmp/hello
The m5out/stats.txt shows (among other things)...
system.cpu.dcache.ReadReq_hits::total 881
system.cpu.dcache.WriteReq_hits::total 917
system.cpu.dcache.ReadReq_misses::total 54
system.cpu.dcache.WriteReq_misses::total 42
Why is an empty function showing so much hits and misses? Are the hits and misses caused by libc? If so, then what is the purpose of m5_reset_stats() and m5_dump_stats()?
I would check in the stats.txt file if there are two chunks of
---Begin---
---End-----
because as you explained it, the simulator is supposed to dump the stats at dump_stats(0,0) and at the end of the run. So, it seems like you either are looking at one of those intervals (and I would expect the other interval to have 0 for all stats); or there was a bug in the simulation and the dump_stats() (or reset_stats())didn't actually do anything. That actually happened to me plenty of times, but I am not really sure as to the source of this bug.
If you want to troubleshoot further, you could do the following:
Look at the disassembly of your code and find the reset_stats.w and dump_stats.w
Dump a trace from gem5 and see if it ends up executing the dump and reset instructions and also what instructions (and how many) are executed before/after.
Hope this helps!
I am building a tool to replay logs. Manually parsing the logs is annoying, so I'm wondering if there is a way to simply load a message from the log.
Also, I am not against just using a third-party replay tool if one exists.
First read the log file by any mean you want, getting the individual lines (there is one message per line).
Then build a Data Dictionary:
// Use the version of the XML dictionary that is right for you
FIX::DataDictionary dd("FIX44.XML");
Then, for each line (as std::string str), build a message:
FIX::Message msg(str, dd, false);
Finally, handle the message just like your FIX::Application does, or better, call
yourFixApplication.fromApp(msg, mySessionID);
ValidFIX Log analyzer is an online log parser that makes a good job:
http://www.validfix.com/fix-log-analyzer.html